7 ms·

This line of reasoning always confused me. To upgrade to a stronger scheme, couldn't a service just rehash the prior hashes subsequently with a stronger scheme?

This line of reasoning always confused me. To upgrade to a stronger scheme, couldn't a service just rehash the prior hashes subsequently with a stronger scheme? So for those users you'd have newScheme(oldScheme(password)). Then you could do a one-time migration of users with older scheme to increase the security to the new one.

i386 10y ago
Because $password isn't the original value. It should be a hash written when the password is set and the original is thrown away.
- bdcravens 10y ago
  You don't need original password, hash the hash. if date < '2016-01-01' return newly_hashed == new_hash(old_hash($password))
  - sirius87 10y ago
    And hash twice again during login/password lookup then? Can be done, but tedious.
    - bdcravens 10y ago
      Sure, not ideal, but would prevent mass password updates.
    - mrswag 10y ago
      Yes, but it happens only the first time, if you update the stored hash with newHash(plaintext_password)
- efoto 10y ago
  @pixelcort is correct here, it is possible to do it that way: If a DB has an old hash, call it V1 obtained as H1(password), one can apply a newer hashing scheme H2(V1) and save V2. To avoid having two classes of users forever one can always apply H2(H1(password)) for new users. It appears though, that this is not what dropbox did, when they changed the scheme to H2 in 2012, applying H2(password) for new users instead.
Swizec 10y ago
I'm rusty on theory, but if I remember correctly, double hashing can reduce entropy and thus leak information and make passwords easier to crack.
- hiou 10y ago
  This one gets it. Most hashes are fixed length
  - Dylan16807 10y ago
    That's not a realistic worry.
Svenskunganka 10y ago
That's a waste of resources, because each subsequent time a user logs in you have to hash the password twice with two different hashing schemes to verify their password. The normal way of doing this is when the next time the user logs in, you use the old hashing scheme to check that the passwords match, if they do, you hash the password with the new hashing scheme and overwrite the old one with the new one. This is often coupled with invalidating all session tokens to force all users to login again (in order to speed up the process of migrating active users to the new hashing scheme). The problem comes with the users that hasn't logged in for years, they still have their password hashed with the old scheme, but normally you would invalidate those hashes. That means getting rid of them completely so if a data breach would occur, their accounts doesn't have any hashes that could be attacked (UPDATE users SET password=null WHERE hashing_scheme='old'). From the users perspective, this would force them to reset (it's actually set now, not reset) their password via their email.
- medmunds 10y ago
  > each subsequent time a user logs in you have to hash the password twice with two different hashing schemes The first time such a user logs in, you can upgrade their hash to the latest scheme, so there's no extra work on later logins. Django, e.g., does just this, automatically. https://docs.djangoproject.com/en/1.10/topics/auth/passwords/#password-upgrading https://docs.djangoproject.com/en/1.10/topics/auth/passwords...
  - Svenskunganka 10y ago
    That's exactly what I was implying...
    - medmunds 10y ago
      Sorry, I was trying to point out that you can have it both ways. As pixelcort suggested, do a one-time upgrade of all (weak) hashes to newScheme(oldScheme(password). But then as users login, you can upgrade them to just newScheme(password). No need to force a reset just because people haven't logged in recently. I'm familiar with Django, and they happen to have some nice docs on both parts of the process: bulk upgrade to stronger scheme by wrapping [1] and individual upgrade on login [2]. But the technique isn't unique to Django. [1]: https://docs.djangoproject.com/en/1.10/topics/auth/passwords/#password-upgrading-without-requiring-a-login https://docs.djangoproject.com/en/1.10/topics/auth/passwords... [2]: https://docs.djangoproject.com/en/1.10/topics/auth/passwords/#password-upgrading https://docs.djangoproject.com/en/1.10/topics/auth/passwords...
azundo 10y ago
Isn't the point that the old hashes are out there somewhere and if cracked would reveal the plaintext password? This would then allow the attacker to access the compromised account since the password itself has not changed even if hashes are updated by doing newScheme(oldHash).
- medmunds 10y ago
  If your db has already been breached, it's too late to upgrade security on those hashes, true. But if you're trying to proactively strengthen your password hashes to make them more resistant in case of a future breach, this lets you do that with no inconvenience to your users.
  - zepolen 10y ago
    You have a lot to learn about security.
    - medmunds 10y ago
      I'm certain you're right, and I'm here to learn. Genuinely curious about the risks to upgrading password algorithms by wrapping the old hashes. (Because at least one major framework seems to suggest this approach.) Is this an absolute cryptographic disaster, or a tradeoff to weigh against other concerns, or ...? The alternatives seem to be never upgrading your hash algorithms/iterations (which leaves old, weak hashes in your db -- clearly problematic in the event of a breach), or forcing userbase-wide password resets every time you upgrade (which could be a major inconvenience for the users, making it a reason to avoid or delay strengthening your password hashing -- also problematic). [Just to be clear: I'm leaving all of this to my framework--I do know enough not to try to roll my own security. But I'd like to try to understand the decisions the framework maintainers make, and their potential ramifications.]
patio11 10y ago
This works, but if you've previously leaked a copy of the old hashes, then old passwords which are still in use are still only as secure as the old hashing mechanism. They won't be running old hashes against Dropbox's live service, they'll be dropping guessed passwords against Dropbox's live service. It doesn't matter if that password is now secured by bcrypt-with-a-hefty-cost-factor wrapped around MD5, improving its security versus being done in just MD5 -- if the password is right then the attacker will get through.
- erelde 10y ago
  It's the same thing if the user re use their password though.
- tomjen3 10y ago
  As a Dropbox user I am just going to change it back to my old password anyway.
  - zaidf 10y ago
    A good PM would state in the specs to check the new password isn't the same as the old one.
  - StavrosK 10y ago
    Why? Use a password manager, then new passwords become free.
    - mrswag 10y ago
      I know I should, but I can't bring myself to it. I'm constantly switching between three OS, two browsers, different, sometimes auto-resetting computers, and it seems to be too much of a hassle. How do I handle this? The only obvious option is a paper notebook.
      - bbrks 10y ago
        LastPass works fine for me in this scenario (plus a mobile device). I'd rather be on an Open Source password manager, but I've found the sync is always too painful to do yourself.
bigiain 10y ago
That's better for the _next_ time your site is breached and you newScheme hashes get exposed. Doesn't help if $attacker has a list of breached oldScheme(password) hashes, and can crack useful numbers of passwords from you old weak oldScheme hash. They can still log into migrated accounts if they can reverse oldScheme into the characters of password. If you're preemptively upgrading your password hashing aglo with the assumption that you have not (yet) been breached, that works (if your assumption is good). Once the oldScheme hashes are out there though, it's too late.
tedunangst 10y ago
One would hope your hashing scheme involves a salt and maybe even a work factor, and when you start including all the parameters, it's not so simple as A(B(C(P))).

i386 10y ago

Because $password isn't the original value. It should be a hash written when the password is set and the original is thrown away.

bdcravens 10y ago
You don't need original password, hash the hash. if date < '2016-01-01' return newly_hashed == new_hash(old_hash($password))
- sirius87 10y ago
  And hash twice again during login/password lookup then? Can be done, but tedious.
  - bdcravens 10y ago
    Sure, not ideal, but would prevent mass password updates.
  - mrswag 10y ago
    Yes, but it happens only the first time, if you update the stored hash with newHash(plaintext_password)
efoto 10y ago
@pixelcort is correct here, it is possible to do it that way: If a DB has an old hash, call it V1 obtained as H1(password), one can apply a newer hashing scheme H2(V1) and save V2. To avoid having two classes of users forever one can always apply H2(H1(password)) for new users. It appears though, that this is not what dropbox did, when they changed the scheme to H2 in 2012, applying H2(password) for new users instead.

Swizec 10y ago

I'm rusty on theory, but if I remember correctly, double hashing can reduce entropy and thus leak information and make passwords easier to crack.

hiou 10y ago
This one gets it. Most hashes are fixed length
- Dylan16807 10y ago
  That's not a realistic worry.

Svenskunganka 10y ago

That's a waste of resources, because each subsequent time a user logs in you have to hash the password twice with two different hashing schemes to verify their password. The normal way of doing this is when the next time the user logs in, you use the old hashing scheme to check that the passwords match, if they do, you hash the password with the new hashing scheme and overwrite the old one with the new one. This is often coupled with invalidating all session tokens to force all users to login again (in order to speed up the process of migrating active users to the new hashing scheme). The problem comes with the users that hasn't logged in for years, they still have their password hashed with the old scheme, but normally you would invalidate those hashes. That means getting rid of them completely so if a data breach would occur, their accounts doesn't have any hashes that could be attacked (UPDATE users SET password=null WHERE hashing_scheme='old'). From the users perspective, this would force them to reset (it's actually set now, not reset) their password via their email.

medmunds 10y ago
> each subsequent time a user logs in you have to hash the password twice with two different hashing schemes The first time such a user logs in, you can upgrade their hash to the latest scheme, so there's no extra work on later logins. Django, e.g., does just this, automatically. https://docs.djangoproject.com/en/1.10/topics/auth/passwords/#password-upgrading https://docs.djangoproject.com/en/1.10/topics/auth/passwords...
- Svenskunganka 10y ago
  That's exactly what I was implying...
  - medmunds 10y ago
    Sorry, I was trying to point out that you can have it both ways. As pixelcort suggested, do a one-time upgrade of all (weak) hashes to newScheme(oldScheme(password). But then as users login, you can upgrade them to just newScheme(password). No need to force a reset just because people haven't logged in recently. I'm familiar with Django, and they happen to have some nice docs on both parts of the process: bulk upgrade to stronger scheme by wrapping [1] and individual upgrade on login [2]. But the technique isn't unique to Django. [1]: https://docs.djangoproject.com/en/1.10/topics/auth/passwords/#password-upgrading-without-requiring-a-login https://docs.djangoproject.com/en/1.10/topics/auth/passwords... [2]: https://docs.djangoproject.com/en/1.10/topics/auth/passwords/#password-upgrading https://docs.djangoproject.com/en/1.10/topics/auth/passwords...

azundo 10y ago

Isn't the point that the old hashes are out there somewhere and if cracked would reveal the plaintext password? This would then allow the attacker to access the compromised account since the password itself has not changed even if hashes are updated by doing newScheme(oldHash).

medmunds 10y ago
If your db has already been breached, it's too late to upgrade security on those hashes, true. But if you're trying to proactively strengthen your password hashes to make them more resistant in case of a future breach, this lets you do that with no inconvenience to your users.
- zepolen 10y ago
  You have a lot to learn about security.
  - medmunds 10y ago
    I'm certain you're right, and I'm here to learn. Genuinely curious about the risks to upgrading password algorithms by wrapping the old hashes. (Because at least one major framework seems to suggest this approach.) Is this an absolute cryptographic disaster, or a tradeoff to weigh against other concerns, or ...? The alternatives seem to be never upgrading your hash algorithms/iterations (which leaves old, weak hashes in your db -- clearly problematic in the event of a breach), or forcing userbase-wide password resets every time you upgrade (which could be a major inconvenience for the users, making it a reason to avoid or delay strengthening your password hashing -- also problematic). [Just to be clear: I'm leaving all of this to my framework--I do know enough not to try to roll my own security. But I'd like to try to understand the decisions the framework maintainers make, and their potential ramifications.]

patio11 10y ago

This works, but if you've previously leaked a copy of the old hashes, then old passwords which are still in use are still only as secure as the old hashing mechanism. They won't be running old hashes against Dropbox's live service, they'll be dropping guessed passwords against Dropbox's live service. It doesn't matter if that password is now secured by bcrypt-with-a-hefty-cost-factor wrapped around MD5, improving its security versus being done in just MD5 -- if the password is right then the attacker will get through.

erelde 10y ago
It's the same thing if the user re use their password though.
tomjen3 10y ago
As a Dropbox user I am just going to change it back to my old password anyway.
- zaidf 10y ago
  A good PM would state in the specs to check the new password isn't the same as the old one.
- StavrosK 10y ago
  Why? Use a password manager, then new passwords become free.
  - mrswag 10y ago
    I know I should, but I can't bring myself to it. I'm constantly switching between three OS, two browsers, different, sometimes auto-resetting computers, and it seems to be too much of a hassle. How do I handle this? The only obvious option is a paper notebook.
    - bbrks 10y ago
      LastPass works fine for me in this scenario (plus a mobile device). I'd rather be on an Open Source password manager, but I've found the sync is always too painful to do yourself.

bigiain 10y ago

That's better for the _next_ time your site is breached and you newScheme hashes get exposed. Doesn't help if $attacker has a list of breached oldScheme(password) hashes, and can crack useful numbers of passwords from you old weak oldScheme hash. They can still log into migrated accounts if they can reverse oldScheme into the characters of password. If you're preemptively upgrading your password hashing aglo with the assumption that you have not (yet) been breached, that works (if your assumption is good). Once the oldScheme hashes are out there though, it's too late.

tedunangst 10y ago

One would hope your hashing scheme involves a salt and maybe even a work factor, and when you start including all the parameters, it's not so simple as A(B(C(P))).