Consider back in the 90s you\'re ahead of the curve, you hashed and salted your
ID: 661623 • Letter: C
Question
Consider back in the 90s you're ahead of the curve, you hashed and salted your passwords with SHA, and you're a big site, millions of accounts, etc.
Well the web evolves, and over time more advanced security measures become expected and common place. Key stretching, more advanced hardware, cheaper hardware, etc.
Lets imagine that not all of your customers log in every year. You don't care how often they log in, if they created the account in the 90s and want to access it in 2014, thats perfectly fine. But you want to upgrade their security.
Imagine an evolution in security where you go from a simple SHA hash, to PBKDF, to Bcrypt, to Scrypt, and into the futureCrypt. Throughout this evolution, you increase repetitions and any other configurable values that may come into existence as hardware increases in power and affordability.
I guess
1) do people do this, is this a thing?
And
2) What are the current strategies or theoretical strategies for upgrading password security in such a way?
Explanation / Answer
This is being done and the strategy mostly used is this one:
- Generate the hash with the old algorithm sha1(password+salt)
- Now implement the new hashing function (let's take scrypt)
- Take the the database and run your scrypt(hash) on all saved password hashes
- Implement your code scrypt(sha1(password+salt)) so that it also uses this algorithm to change passwords
You can then take it a step further and also implement so that when a user logs in his password is changed subesequently so the hash of scrypt(password) (you can keep a list of user-ids which use the previous algorithm and use it to authenticate them, migrate the password after logging in to the new algorithm and then take them out of the list). The benefit here is that all your passwords will be using scrypt even the ones having dormant accounts.