4 ms·

Is there a good way to update passwords to a new encryption scheme? the article tries to ding amazon for failing to do this, but I can't think of a way to reinf

by tel 16y ago

Is there a good way to update passwords to a new encryption scheme? the article tries to ding amazon for failing to do this, but I can't think of a way to reinforce the passwords without announcing that there's a flaw in the implementation. Is there a standard way around this?

nbpoole 16y ago
Yes. Sort of. ;-) The standard way I've seen is to do this when the user logs in: if in checking their password you notice they're using the old hashing scheme, you use the plaintext password provided by the login process to generate a hash using the new scheme. For example, lets say you're a PHP function that takes in $username and $password (both plaintext). You're "upgrading" from unsalted MD5 to unsalted SHA1 (NOTE: DO NOT DO THIS IN REAL LIFE. READ http://codahale.com/how-to-safely-store-a-password/ http://codahale.com/how-to-safely-store-a-password/ AND UNDERSTAND WHY UNSALTED MD5 / SHA1 SHOULD NOT BE USED FOR PASSWORD SECURITY). Your code to upgrade the hashes would look something like this: if (md5($password) === $cur_user['password']) $cur_user['password'] = sha1($password); Now, you may have realized that there's a flaw here. Since the server uses the hash for verification, it can't be 100% sure that the plaintext password is actually correct. If there's a collision (two plaintexts hashing to the same value), you could inadvertently store the wrong password in your new hash. In this case, the problem is that passwords longer than eight characters are silently truncated. So, if my password is something like supersecretpassword, I could also enter supersec and have it accepted (since they hash to the same value). That would be a problem for Amazon, since someone could make a typo in their password and have the wrong value stored in the new hash.
- Groxx 16y ago
  >Now, you may have realized that there's a flaw here. ... Not really. It's more of a fundamental property of hashing functions, and it's technically true of any hashing function, and collisions are nearly just a technical possibility unless you're using an incredibly-small hash output. Though that would likely be preferable to truncating before hashing - fewer practical collisions and safer, as reversing the hash is less useful due to more collisions actually existing in breakably-short password lengths.
  - lvh 16y ago
    I think he was thinking of truncation by crypt, so that even passwords that are completely different (bar the first 8 chars, bar collisions) would match.
    - drivebyacct2 16y ago
      I think the point is, the user's password could potentially be set to something other than the original if they happen to type it "close enough". That would cause major confusion going forward.
  - nbpoole 16y ago
    You're right. The reason I pointed it out as a flaw is because it has major consequences in this case. It's true for every hash function, but highly unlikely to happen in most cases.
- deleted 16y ago
  [deleted]
rookie 16y ago
Reset and request password update on next login.
jmillikin 16y ago
A few options: 1. They could force everybody with an old password to reset it. This would announce there was a flaw, but shouldn't be any riskier than having a "forgot password" link. 2. Silently upgrade passwords as users log in. This is risky, because many users might not log in for months. 3. Use their clusters to reverse weak password digests. This would be mostly transparent to customers, but runs a risk of accidentally locking out some customers. For example, if "bar" and "foo" both crypt() to "abcd123", and the user has password "foo", the recover-and-redigest method might change the password to "bar". 4. Wrap old passwords in a new digest -- presumably they have some way to determine which algo is used per-user. They could treat the output of crypt() as the input to a more secure digest, like scrypt, and then just store "crypt-plus-scrypt" in their database as the digest type.
- bdonlan 16y ago
  They can't do #4, as they don't have the old password. They'd either end up having to reverse the hash (with the same problems as #3), in which case why keep the crypt() hash? Or they could use the crypt() output as the input to the new hash, which wouldn't change the set of passwords accepted, and therefore wouldn't help at all.
  - jmillikin 16y ago
    Wrapping the output of crypt() should reduce how many passwords would be compromised if an attacker gained access to the password database. That's the whole point of using digested passwords instead of plaintext.
    - yuhong 16y ago
      Not to mention it makes attacks against the hash slower.

by tel 16y ago

nbpoole 16y ago

Yes. Sort of. ;-) The standard way I've seen is to do this when the user logs in: if in checking their password you notice they're using the old hashing scheme, you use the plaintext password provided by the login process to generate a hash using the new scheme. For example, lets say you're a PHP function that takes in $username and $password (both plaintext). You're "upgrading" from unsalted MD5 to unsalted SHA1 (NOTE: DO NOT DO THIS IN REAL LIFE. READ http://codahale.com/how-to-safely-store-a-password/ http://codahale.com/how-to-safely-store-a-password/ AND UNDERSTAND WHY UNSALTED MD5 / SHA1 SHOULD NOT BE USED FOR PASSWORD SECURITY). Your code to upgrade the hashes would look something like this: if (md5($password) === $cur_user['password']) $cur_user['password'] = sha1($password); Now, you may have realized that there's a flaw here. Since the server uses the hash for verification, it can't be 100% sure that the plaintext password is actually correct. If there's a collision (two plaintexts hashing to the same value), you could inadvertently store the wrong password in your new hash. In this case, the problem is that passwords longer than eight characters are silently truncated. So, if my password is something like supersecretpassword, I could also enter supersec and have it accepted (since they hash to the same value). That would be a problem for Amazon, since someone could make a typo in their password and have the wrong value stored in the new hash.

Groxx 16y ago
>Now, you may have realized that there's a flaw here. ... Not really. It's more of a fundamental property of hashing functions, and it's technically true of any hashing function, and collisions are nearly just a technical possibility unless you're using an incredibly-small hash output. Though that would likely be preferable to truncating before hashing - fewer practical collisions and safer, as reversing the hash is less useful due to more collisions actually existing in breakably-short password lengths.
- lvh 16y ago
  I think he was thinking of truncation by crypt, so that even passwords that are completely different (bar the first 8 chars, bar collisions) would match.
  - drivebyacct2 16y ago
    I think the point is, the user's password could potentially be set to something other than the original if they happen to type it "close enough". That would cause major confusion going forward.
- nbpoole 16y ago
  You're right. The reason I pointed it out as a flaw is because it has major consequences in this case. It's true for every hash function, but highly unlikely to happen in most cases.
deleted 16y ago
[deleted]

rookie 16y ago

Reset and request password update on next login.

jmillikin 16y ago

A few options: 1. They could force everybody with an old password to reset it. This would announce there was a flaw, but shouldn't be any riskier than having a "forgot password" link. 2. Silently upgrade passwords as users log in. This is risky, because many users might not log in for months. 3. Use their clusters to reverse weak password digests. This would be mostly transparent to customers, but runs a risk of accidentally locking out some customers. For example, if "bar" and "foo" both crypt() to "abcd123", and the user has password "foo", the recover-and-redigest method might change the password to "bar". 4. Wrap old passwords in a new digest -- presumably they have some way to determine which algo is used per-user. They could treat the output of crypt() as the input to a more secure digest, like scrypt, and then just store "crypt-plus-scrypt" in their database as the digest type.

bdonlan 16y ago
They can't do #4, as they don't have the old password. They'd either end up having to reverse the hash (with the same problems as #3), in which case why keep the crypt() hash? Or they could use the crypt() output as the input to the new hash, which wouldn't change the set of passwords accepted, and therefore wouldn't help at all.
- jmillikin 16y ago
  Wrapping the output of crypt() should reduce how many passwords would be compromised if an attacker gained access to the password database. That's the whole point of using digested passwords instead of plaintext.
  - yuhong 16y ago
    Not to mention it makes attacks against the hash slower.