2

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?

Andrew Hoffman
  • 1,997
  • 15
  • 17
  • "is this a thing?" is not a very precise question. Would you care to edit your question to frame a more precise technical question? – D.W. Jun 19 '14 at 21:07

2 Answers2

6

Upgrading passwords hashes is a thing. Indeed, as per password hashing theory, the iteration count in a good password hashing function (e.g. bcrypt) is a trade-off: you make the function as slow as you can tolerate in your current context. When you buy new, faster hardware, you can increase the iteration count, and thus you should. The iteration count allows to counter the effects of Moore's Law, but this works only as long as the count is indeed regularly increased.

The generic method is to wait for the user to come back, and re-hash the password with the new parameters (or even new function) at that point where your server indeed obtains the password and can work on it. People who do that often couple it with an expiry policy (accounts which have not been accessed in two years are closed or at least "frozen").

If we want to do more, i.e. upgrading password hashes in an offline fashion (without waiting for the user to show up), then we have to put our hands in the crypto. One can devise some nesting hashing mechanisms as described in this answer, but that's crypto design so one should be extra careful and basically refrain from it. Generically, you "hash the hash" to (temporarily) strengthen a hash value until the user comes back.

For the ongoing Password Hashing Competition, the call for candidates listed as desirable feature:

Ability to transform an existing hash to a different cost setting without knowledge of the password.

Such a feature requires a specific internal structure. Some PHC candidates offer it, e.g. mine.

Community
  • 1
Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
  • Wow yeah that would be extremely useful. I'm hoping for someone to make something like SCrypt that can increase by memory and CPU separately. I guess where having at least X amount of memory is required to even feasibly execute, with a separate repetition configuration. Last time I remember playing with a scrypt api, all of it was tied to the same value. Adding in the ability to upgrade the hash without knowing the password would be the ideal KDF for simple future-proofing. – Andrew Hoffman Jun 19 '14 at 15:47
4

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.

Lucas Kauffman
  • 54,229
  • 17
  • 113
  • 196
  • Ok let me know if I get this straight. Track KDF tech, Algorith of KDF, repetitions, other values stored alongside the normal stuff. If password is up to date, perform newTech(password+salt, newArgs), if they're behind a little bit, use newTech(oldTech(password+salt, oldArgs), newArgs) authentication, but before scrapping the plaintext, update their password to newTech(password+salt, newArgs). – Andrew Hoffman Jun 19 '14 at 15:30
  • Yep you got it. – Lucas Kauffman Jun 19 '14 at 15:32