Agfdhyk

Let's say I have a database with a bunch of users in it. This user database would typically have a hashed password per user. Would it be bad practice to prefix this hash with the hashing algorithm used?

For instance, instead of the hash aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d, I store sha1_aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d, since the method for making the hash is SHA1.

I noticed Argon2 does this, and I actually think it is quite convenient, because it makes it easier to partially migrate to newer hashing algorithms for newer users over time.

I don't use SHA1 in my production code for passwords. SHA1 was chosen randomly. This question is not about the use of the hashing method.

Many different password hashing systems do this. The type of hashing mechanism used should not be (and should not need to be) a secret. Kerckhoffs's principle says:

A cryptosystem should be secure even if everything about the system,
except the key, is public knowledge.

So, if your system is properly secure, it should not matter if the hash mechanism is exposed.

I agree with schroeder that this is OK to do. Even without a prefix, an attacker can probably figure out what algorithm you are using. And anyway, it is the strength of the hashing algorithm that protects the passwords, not the secrecy of the algorithm.

Note that many hashing algorithms and libraries already do this for you. They embed all the relevant information - algorithm, cost factors, salt, the actual hash - into one serialized string. See for instance the Modular Crypt Format or the PHP password_hash function. So don't go making up your own scheme. If you are using a descent hashing library you already got one.

Don't use SHA1 to hash passwords, though. That is not OK.

No, it's not bad practice, and arguably, you should keep this information.

As you observe, this allows you to change algorithm for new passwords whenever you like, without invalidating all users' existing passwords (doing that tends to make you unpopular, for some reason).

There's an argument that this allows an attacker to search out the older, weaker passwords to attack first, but you haven't reduced their security at all (assuming Kerckhoff's Principle, that the algorithm itself mustn't need to be a secret).

It's good practice to store the hashing algorithm, but proper password hashing functions such as Argon2 and PBKDF2 already take care of this. It is however bad practice to use SHA1 or SHA256 alone for password hashing because they're a fixed (and relatively small) amount of work to crack using dictionary attacks and brute force. Those passwords should be migrated to a secure hashing function by rehashing the password on their next login. See https://crypto.stackexchange.com/a/45405 for details.

It's not bad practice, it's actually a common thing to do. In fact if you open the /etc/shadow file on a linux machine you will see your hashed password prefixed with $x$salt$ where x is a number indicating which hashing algorithm was used.

Now a few things to consider:

• do not use SHA1 directly as a hashing algorithm. Use bcrypt, scrypt, or argon2 instead (which you did mention but this can't be repeated too much). These do use simple hashing algorithm like SHA1 as a base, but they run it in a special way that makes it resistant to attacks.


• for practical reasons, since you're using a database and not a file, you might want to store the hashing method and salt in separate rows. However you can also choose to store the string starting with $x$salt$ in your database, and parse the salt and hashing method from that string at the time you check the password. It's probably fast enough that it makes no significant difference. And in both cases the security of your system will be the same.