Storing password hash params in DB

[amdest]

Hello, Janko!

I've a question: are there any reasons why hashed passwords stored in DB along with hashing params?

Example:

$argon2id$v=19$m=65536,t=2,p=1$nR0yaraoE/TjsH2SDt3H8g$d4l......

I mean, if hashing params are consistent through the app, why do we need to store it in DB, helping a potential attacker to understand what algorithm and params were used?

Isn't it better to strip $argon2id$v=19$m=65536,t=2,p=1 part from password hash before store it?

Thank you!

[janko]

This is the Argon2id hash format that follows the Argon2 specification, it shouldn't be changed. bcrypt also does something similar by including the cost inside the hash. This allows you to change the default parameters later on, in case of Argon2 that would be parallelism/iterations/memory. If these parameters weren't part of the hash, you wouldn't be able to change them for new passwords without breaking old passwords. That would mean accounts would become more vulnerable over time as computers get stronger.

[amdest]

It's a bit strange to me, tbh.
If we change params for new users — existing users still vulnerable to stronger computers.
Wouldn't it be better to force all users to resubmit their passwords to match new params in case we change them?

OK, I get the point, it's not a problem.

Thanks for quick reply.

[janko]

It's not needed that users resubmit their passwords to update the hash, the hash can be updated automatically on successful password login. Rodauth has the update_password_hash feature that does this.

Including params in the hash is simply how bcrypt and argon2 ruby gems are designed to work.

[amdest]

My bad. Didn't know that.
Thank you.