Should I store the hash function name in the DB when hashing passwords?

Question

In regards to saving a salted hash version of the user's password, I save in the DB the hashed salted password and the salt used before hashing it.

Should I also save in the DB the name of the algorithm used to hash the salted password (e.g. SHA1 or MD5 [I am not going to use MD5!]) so in case of someone finding a breach in the algorithm I use, I could switch to use another algorithm for future users ?

Notice: I'm not talking about the algorithm used to generate the random hash.

Answer 1

Yes, this is a good idea. It costs you very little (a few bytes per entry), and means that you can change and improve how you store passwords in future. For instance, suppose you'd started using this method with MD5 some years ago - it would now make it a trivial matter to upgrade to SHA1 or something else more secure by updating each user's password hash when they next log in.

Note you should be using something like PBKDF2 to hash your passwords, not just a salted hash.

Answer 2

If you use a strong cryptographic hash function in the first place, there will probably be no reason to switch to a stronger hashing function.

There is the website keylength.com that has a summary of the most important recommendations for information security in computing. Currently, the chosen hash function should have a length of 160 bit or more – the more the better.

And if you’re looking for a versatile format, you can use the modular crypt format that does contain an identifier of the hash function, the used salt, the digest, and further information (e.g. cost factor) in the form:

$<id>$[<parameters>$]<salt><digest>

Many suggest to use bcrypt for passwords as its additional cost parameter is to adjust the computational costs of the hashing.

Answer 3

This is one of those personal preference things. In the event that a weakness in an hashing algorithm is found, you will need to alter how user passwords are stored and verified. There are multiple ways to do this and storing the name of the hash is a valid alternative. Assuming that

• You want to switch to a better hashing alternative if a weakness is found
• You're not storing plaintext passwords (which if you are, you've got bigger problems)

you will either need to automatically generate new passwords for your users with the new hashing algorithm (and notify them) or have them change or verify their password on next login. The approach of storing the algorithm helps facilitate the second alternative (which I believe is the better option).

Technically, storing the hash algorithm will not make the passwords any less secure if the database is penetrated, and it allows you greater flexibility when you wish to change algorithms.