Credit for this follow-up goes to Earl D. Fife, PhD, CISSP, CCE, Professor of Mathematics and Computer Science, Calvin College Michigan
In the salted hash stored in the UUID file, the salt is displayed in plaintext as the first 4 bytes (6254AE48 in your example).
Recall this Figure from Passwords Part 1
Indeed, the OS needs to see this in order to complete the authentication of the user at login. Using the salt you can easily compute the hash itself (the remaining 20 bytes) for the empty password you chose.
Open up a terminal session and write the command:
echo -n 6254AE48 | xxd -r -p | openssl dgst -sha1
Output of Terminal Command
(The portion after the first pipe is to convert the ASCII string into binary because that is what is prepended to the password before the sha1 digest is created. In your example the password is null so only the salt is hashed.)
To do the same thing with a password, say “openme”, I would use the pair of commands:
export salt=`echo -n 6254AE48 | xxd -r -p`
printf "%s%s" $salt openme | openssl dgst -sha1
where the first line converts the salt to the proper form and the second line concatenates that with the password then computes the hash.
Output of pair of Terminal Commands
Let’s apply the same pair of Terminal commands to the ‘null’ password to show our password hash does indeed match.
Output of pair of Terminal Commands applied to ‘null’ password
Notice how the hash value does indeed match the Shadow file hash for “goof” in the first image.
The other point I would make is that the reason that salted passwords are resistant to attacks using rainbow tables or pre-computed hash tables is that with a 4-byte hash, each possible password has 2^32 possible hashes that would have to be addressed. So to obtain the same success rate for salted hashes that you have with a table of unsalted hashes, you would need to increase your table size by a factor of 2^32, or over 4 billion.