4 ms·

The fact that this still happens so frequently even with libraries that make things so easy boggles my mind. Was the engineer who designed this system developin

The fact that this still happens so frequently even with libraries that make things so easy boggles my mind. Was the engineer who designed this system developing under a rock? Did not a single other person take a minute to review their code?

dboreham 10y ago
fwiw I don't see this kind of problem being solved with code reviews (although of course it is possible someone could have spotted a problem in a review). The proper way imho to address this kind of risk is to have someone in authority responsible for security, and that person needs to do their job which would include asking questions like "how are we hashing passwords?". Then that person should go dump the database and look for themselves since the answer supplied to the above question is often incorrect. That said, this could have been a deliberate design decision -- when changing hash function the question arises "what about all the existing stored hashes we have?". One possible answer is "leave them as-is, we'll only compute a new hash when the user changes their password". Of course this is the wrong answer, but I've been involved with hashing transition projects at major sites where this was suggested as a serious option. Better design clearly would have been to update the hash the next time the user logs in, with an expiry/grace time of a few weeks to catch accounts that don't see the user presenting a new plaintext password (force password reset on those accounts after the grace period). This of course would have also lowered site traffic slightly due to users never re-logging in after the password reset.
- icebraining 10y ago
  Another option is just hashing the current hash, ie., if you have sha1(pass), you can apply bcrypt and store bcrypt(sha1(pass)). Possibly add a per-user flag to indicate this was done, which can be cleared after the user logs in the next time and you can store simply bcrypt(pass).

dboreham 10y ago

fwiw I don't see this kind of problem being solved with code reviews (although of course it is possible someone could have spotted a problem in a review). The proper way imho to address this kind of risk is to have someone in authority responsible for security, and that person needs to do their job which would include asking questions like "how are we hashing passwords?". Then that person should go dump the database and look for themselves since the answer supplied to the above question is often incorrect. That said, this could have been a deliberate design decision -- when changing hash function the question arises "what about all the existing stored hashes we have?". One possible answer is "leave them as-is, we'll only compute a new hash when the user changes their password". Of course this is the wrong answer, but I've been involved with hashing transition projects at major sites where this was suggested as a serious option. Better design clearly would have been to update the hash the next time the user logs in, with an expiry/grace time of a few weeks to catch accounts that don't see the user presenting a new plaintext password (force password reset on those accounts after the grace period). This of course would have also lowered site traffic slightly due to users never re-logging in after the password reset.

icebraining 10y ago
Another option is just hashing the current hash, ie., if you have sha1(pass), you can apply bcrypt and store bcrypt(sha1(pass)). Possibly add a per-user flag to indicate this was done, which can be cleared after the user logs in the next time and you can store simply bcrypt(pass).