3 ms·

> SHA-2 or Bcrypt would be a better choice. As the sibling comment points out, SHA-2 is worthless for storing passwords. A GPU can crank through an obscene num

> SHA-2 or Bcrypt would be a better choice. As the sibling comment points out, SHA-2 is worthless for storing passwords. A GPU can crank through an obscene number of SHA-2 hashes per second. Bcrypt is is intentionally much slower and harder to use a GPU to brute force. The two algorithms are almost totally unrelated and it's concerning they were mentioned together.

TeMPOraL 7y ago
Sure. But that advice was written 12 years ago. I'd be surprised if they didn't update their password storage since then.
- krzyk 7y ago
  How do you update password storage if you don't store the passwords only hashes? You could upgrade it for new users, but for old ones? (e.g. I don't change passwords often)
  - TeMPOraL 7y ago
    You ask people to change their passwords, and when they do so, you store them with the new scheme. You can do that by e.g. requiring everyone to change their password on their next login/visit.
    - icebraining 7y ago
      You don't even need to ask people to change their passwords; when they login, you have a copy of the original password, so you can just store the new hash over the old.
  - Crinus 7y ago
    You could rehash the password the next time the user logs in.
  - ShinTakuya 7y ago
    I updated a DB from MD5 to BCrypt at my last job. Essentially on the next login I updated the password (since the password isn't hashed on the client end). So all active users got switched over. After a relatively short period I reset the remaining passwords and forced users to send password reset emails to login.
  - erpellan 7y ago
    Onion hash: hash the existing hash with the new algorithm.
    - hopscotch 7y ago
      That throws away entropy, but I suppose so long as very few hash collisions of a password are likely to be real passwords themselves it would be harmless.
  - EvilTerran 7y ago
    When a user whose password is hashed the old way logs in, after checking the password they just supplied against your stored old hash but before forgetting the plaintext, you can compute the new hash & update your records. Of course, that only works for active users - it won't upgrade anyone that never logs in. Depending on just how weak the old hash is, you may want to eventually cut off any lingering un-upgraded accounts: just forget their old hash, requiring them to go through your password reset process should they ever come back. If you've left it long enough, those accounts will probably never be used again anyway, so that should be NBD.
  - bluedino 7y ago
    If they aren't salted, just generate your own rainbow table!
blowski 7y ago
He wrote it in 2007.
- dagenix 7y ago
  He said to use Bcrypt or SHA-2. One of those algorithms was explicitly designed for password storage, the other was not. They aren't really the same class of algorithm. As such, it doesn't really make sense to suggest one as an alternative to the other. Nobody ever suggests uses Bcrypt as the hash in a hashtable - even if it technically could be made to work. GPUs that could crank through trillions of hashes per second might not have existed, but, that doesn't make it good advice. Good advice would have been "use bcrypt or, if you can't, PBKDF2 (or maybe some other library that implements a variant of one of those)"
killjoywashere 7y ago
To be fair, Jeff's post was written in 2007 ... this predates Khanna's PS3 clusters. CUDA was released the same year. So I'm not sure it would be obvious in 2007 that SHA-2 would be "worthless for storing passwords".
- dagenix 7y ago
  PBKDF2 seems to have been specified in 2000 as part of RFC 2898 [1] and, IIRC, existed before then. Bcrypt is from 1999 [2]. Both of those algorithms were explicitly designed to be slow. My understanding is that PBKDF2 wasn't explicitly designed for password storage, but that it was recognized as being useful for that early on. Bcrypt was explicitly designed for password storage. The article referenced came out 7 years later. IMO: there was evidence that salted SHA-2 was not secure. [1] - https://tools.ietf.org/html/rfc2898#section-5.2 https://tools.ietf.org/html/rfc2898#section-5.2 [2] - https://en.wikipedia.org/wiki/Bcrypt https://en.wikipedia.org/wiki/Bcrypt
viraptor 7y ago
> SHA-2 is worthless for storing passwords It really depends on what the person means. Yes, single sha-2 hash is pretty useless. But that's often not what's really happening. For example libcrypt is used in many cases with the default $6$ format which uses thousands of rounds of sha512. That's still "password hashed with sha-2".
- dagenix 7y ago
  If that were the case, his advice ought to have been something like "use libcrypt with SHA-2" or something like that. Just "use SHA-2" was kinda useless in 2007 and hasn't gotten more useful since then.

TeMPOraL 7y ago

Sure. But that advice was written 12 years ago. I'd be surprised if they didn't update their password storage since then.

krzyk 7y ago
How do you update password storage if you don't store the passwords only hashes? You could upgrade it for new users, but for old ones? (e.g. I don't change passwords often)
- TeMPOraL 7y ago
  You ask people to change their passwords, and when they do so, you store them with the new scheme. You can do that by e.g. requiring everyone to change their password on their next login/visit.
  - icebraining 7y ago
    You don't even need to ask people to change their passwords; when they login, you have a copy of the original password, so you can just store the new hash over the old.
- Crinus 7y ago
  You could rehash the password the next time the user logs in.
- ShinTakuya 7y ago
  I updated a DB from MD5 to BCrypt at my last job. Essentially on the next login I updated the password (since the password isn't hashed on the client end). So all active users got switched over. After a relatively short period I reset the remaining passwords and forced users to send password reset emails to login.
- erpellan 7y ago
  Onion hash: hash the existing hash with the new algorithm.
  - hopscotch 7y ago
    That throws away entropy, but I suppose so long as very few hash collisions of a password are likely to be real passwords themselves it would be harmless.
- EvilTerran 7y ago
  When a user whose password is hashed the old way logs in, after checking the password they just supplied against your stored old hash but before forgetting the plaintext, you can compute the new hash & update your records. Of course, that only works for active users - it won't upgrade anyone that never logs in. Depending on just how weak the old hash is, you may want to eventually cut off any lingering un-upgraded accounts: just forget their old hash, requiring them to go through your password reset process should they ever come back. If you've left it long enough, those accounts will probably never be used again anyway, so that should be NBD.
- bluedino 7y ago
  If they aren't salted, just generate your own rainbow table!

blowski 7y ago

He wrote it in 2007.

dagenix 7y ago
He said to use Bcrypt or SHA-2. One of those algorithms was explicitly designed for password storage, the other was not. They aren't really the same class of algorithm. As such, it doesn't really make sense to suggest one as an alternative to the other. Nobody ever suggests uses Bcrypt as the hash in a hashtable - even if it technically could be made to work. GPUs that could crank through trillions of hashes per second might not have existed, but, that doesn't make it good advice. Good advice would have been "use bcrypt or, if you can't, PBKDF2 (or maybe some other library that implements a variant of one of those)"

killjoywashere 7y ago

To be fair, Jeff's post was written in 2007 ... this predates Khanna's PS3 clusters. CUDA was released the same year. So I'm not sure it would be obvious in 2007 that SHA-2 would be "worthless for storing passwords".

dagenix 7y ago
PBKDF2 seems to have been specified in 2000 as part of RFC 2898 [1] and, IIRC, existed before then. Bcrypt is from 1999 [2]. Both of those algorithms were explicitly designed to be slow. My understanding is that PBKDF2 wasn't explicitly designed for password storage, but that it was recognized as being useful for that early on. Bcrypt was explicitly designed for password storage. The article referenced came out 7 years later. IMO: there was evidence that salted SHA-2 was not secure. [1] - https://tools.ietf.org/html/rfc2898#section-5.2 https://tools.ietf.org/html/rfc2898#section-5.2 [2] - https://en.wikipedia.org/wiki/Bcrypt https://en.wikipedia.org/wiki/Bcrypt

viraptor 7y ago

> SHA-2 is worthless for storing passwords It really depends on what the person means. Yes, single sha-2 hash is pretty useless. But that's often not what's really happening. For example libcrypt is used in many cases with the default $6$ format which uses thousands of rounds of sha512. That's still "password hashed with sha-2".

dagenix 7y ago
If that were the case, his advice ought to have been something like "use libcrypt with SHA-2" or something like that. Just "use SHA-2" was kinda useless in 2007 and hasn't gotten more useful since then.