3 ms·

I do not agree with your #2 regarding making users re-create their password. Assuming you haven't been hacked yet the old password is still secret. Therefore y

I do not agree with your #2 regarding making users re-create their password. Assuming you haven't been hacked yet the old password is still secret. Therefore you modify your login system so that when the user next logs in: * Check password against old hash * If old hash exists and matches user's password then re-hash the password using new hash and save new hash in new field * If old hash does not exist then just check against new hash only. Run the above code for X time (X being the time it takes Y% (Defined by company) of your users to login at least once. After X time THEN you start forcing the remainder to switch over. Done properly for the vast majority of your users should not even know you have changed anything. [EDIT] - With some extra code you could probably avoid having to create a new field for the new hash by just checking against one hash field using old algorithm then new algorithm. This would avoid a potentially costly DB migration.

jaf656s 14y ago
It's much safer to just hash twice: the first time using your old hash function and again using a secure hash. Then to migrate you only have to update all your customer's password hashes in place. Additionally, if you lose your database, you don't lose all the old, weak password hashes.
- rmrfrmrf 14y ago
  Ooo, I hadn't thought of that! For some reason, I had it in my mind that some insecure hashing algorithm as the base would result in an insecure resulting hash, but of course that all goes out the window when your whole password table is out in the open. I'm glad you mentioned "safer", because for some reason rurounijones's approach made me nervous, but I couldn't quite put my finger on it. Here's some more discussion on the issue: http://crypto.stackexchange.com/questions/2945/is-this-password-migration-strategy-secure http://crypto.stackexchange.com/questions/2945/is-this-passw... (I found that from here: http://stackoverflow.com/questions/3955223/password-hashing-how-to-upgrade http://stackoverflow.com/questions/3955223/password-hashing-...).

jaf656s 14y ago

It's much safer to just hash twice: the first time using your old hash function and again using a secure hash. Then to migrate you only have to update all your customer's password hashes in place. Additionally, if you lose your database, you don't lose all the old, weak password hashes.

rmrfrmrf 14y ago
Ooo, I hadn't thought of that! For some reason, I had it in my mind that some insecure hashing algorithm as the base would result in an insecure resulting hash, but of course that all goes out the window when your whole password table is out in the open. I'm glad you mentioned "safer", because for some reason rurounijones's approach made me nervous, but I couldn't quite put my finger on it. Here's some more discussion on the issue: http://crypto.stackexchange.com/questions/2945/is-this-password-migration-strategy-secure http://crypto.stackexchange.com/questions/2945/is-this-passw... (I found that from here: http://stackoverflow.com/questions/3955223/password-hashing-how-to-upgrade http://stackoverflow.com/questions/3955223/password-hashing-...).