Re: Adjust bcrypt cost to prevent future password hash attacks

[muba]

If I read you correctly, your idea is to re-hash passwords every now and then as computers get faster, am I right? Assuming that I am, here's my question.

Once the hash of a password gets stored, we really have no longer have an idea of what the actual password is. In an ideal world, even when the user tries to log in, a hash of his password is sent, and then the stored hash and the stored hash are compared to determine the successfulness of a login attempt.

Given this, how do you propose the password is re-hashed without having the original password to work from?

[andreas1234567]

.. when the user tries to log in, a hash of his password is sent

No. When the user tries to log in, the password is sent (encrypted in transit, then decrypted (in memory only) to clear text on the server).

Given this, how do you propose the password is re-hashed without having the original password to work from?

At next successful login. Add password expiry functionality (i.e. max 30 days), and we can ensure that all passwords are either
• invalid, or
• re-hashed with increased cost over the next 30 days.