Is there any advantage to re-hashing stored passwords at login time?

Question

I'm in the process of updating several projects from using various insecure/horribly insecure MD5-based password hashes. I'm now at least somewhat better informed on best practices, but I still wonder if I'm doing something wrong. I haven't seen the specific process I'm implementing used elsewhere, but at least one SO user seems to want to do something similar. In my case:

• Password hashes are generated using bcrypt. (Since the proper options seem to be bcrypt, scrypt, or pbkdf2 and bcrypt was most easily accessible to me in PHP.)

• A different, random, salt is used for each hash. (To prevent attackers from generating a custom rainbow table calculated with a single, static salt.)

• The hash, algorithm settings, and salt are stored together. (Since that's what PHP's crypt function give me for the hash value.)

• After a successful login, the hash is re-calculated with a new random salt.

It's that last step that I'm wondering about. My intention here to to allow updates to the hashing algorithm as time passes so users who regularly log in will have their passwords stored in the most secure format available.

My questions are:

1. Is this a waste of time?

2. Are there any dangers in doing this?

Answer 1

UPDATE

Re delnan's comment : If you are re-hashing the already hashed password, don't -- You never know what vulnerabilities may occur and be found in chaining up hashes. Obviously the other side of that is you need to compute the entire hash-chain every time you validate the user secret -- so just re-hash the cleartext.

ORIGINAL

I upvoted halfway through reading. It seems like you're someone who's asking the right kind of questions to be doing this kind of work.

1. Not a waste of time.
2. There are always dangers. Someone could obtain your users' passwords by torture or, more likely, social engineering. Someone could have access to vast resources and along with your shadow password file still manage to crack the passwords. Someone could compromise your server secretly insert a trojan that intercepts the users cleartext passwords at successful login.

So there is no guarantee of perfect security. Ever. But I'm sure you know that already. Which is why I'd like to add only one thing:

• Encourage users to choose hard to crack passwords.

And, strictly speaking, if your only reason for rehashing at every login is so that passwords are always stored using the latest update then yes -- your method IS a waste of time, assuming you will not be updating your algorithm at every user's login. So there will be rehashes which use the same algorithm and (presumed) security for two logins in a row. A waste of a few clock cycles on rehashing. Strictly speaking it's not optimized. Why not just include an algo version in your password store, and at login rehash if the system algo is newer than the user's hash algo.

Answer 2

UDPATE

Sorry. Completely missed your point about the use of newer algo's. This is a good thing. :-) But as stated in my original answer below when the algo stays the same it is useless.

ORIGINAL

Rehashing passwords is useless, because if an attacker has already got hold of the hash you aren't preventing anything.

Consider the following:

• I am a user on your site with the hash: 1234567890.
• Some attacker gets hold of that hash.
• I log in again and the hash is changed.
• The attacker doesn't care the hash changes because he only needs one hash to try to break.

So nothing has been prevented. The attacker still has the hash and can still try to break it. A possible attacker is only interested in the final result (the password) and not in the hashes.