Why salted hash is as good for passwords as for breakfast
- By William Jackson
- Dec 02, 2013
Passwords remain the primary means for online authentication and must be protected when stored on a server. Encryption is an option, but it has an inherent weakness in this application because the server authenticating the password must have the key to decrypt it. An attacker who steals a file of encrypted passwords might also steal the key.
Hashing is a better option, especially with the judicious use of salt, according to mathematician Andrew Regenscheid and computer scientist John Kelsey of the National Institute of Standards and Technology’s Computer Security Division.
Encryption is a two-way function; what is encrypted can be decrypted with the proper key. Hashing, however, is a one-way function that scrambles plain text to produce a unique message digest. With a properly designed algorithm, there is no way to reverse the hashing process to reveal the original password. An attacker who steals a file of hashed passwords must then guess the password.
Here’s how it works: A user enters a password and an ID in a browser and sends it (preferably over a secure link) to the authentication server. The server uses the ID to look up the associated message digest. The password submitted by the user is then hashed with the same algorithm, and if the resulting message digest matches the one stored on the server, it is authenticated.
In this process the server does not store or need to see plain-text passwords. Stealing hashed files does the attacker little good because the attacker cannot reverse the hashing process.
But because people rarely use completely random passwords there is a trick that can be used to help guess the passwords in the file. An attacker can run a collection of a million or so commonly used passwords through a hashing algorithm and get a list — called a rainbow table — of associated message digests for these passwords. It is child’s play for a computer to compare a file of stolen password hashes against a rainbow table. For every match, the table will show the password for that hash.
The protection against this is to salt the hash: Add a random number to each password before it is hashed. The resulting message digest is the product of both the password and the salt value and will not match anything on the rainbow table.
Of course, the attacker can always try adding random values to common passwords to find a matching hash, but now the difficulty of guessing the password makes it impractical. The return on investment of such a process is so low that a stolen file of properly hashed and salted passwords is essentially worthless.
William Jackson is freelance writer and the author of the CyberEye blog.