3 ms·

The attraction of bcrypt is that you can tune its work factor to counter increases in computing technology, so that it's very slow to brute-force compared to an

by cheald 16y ago

The attraction of bcrypt is that you can tune its work factor to counter increases in computing technology, so that it's very slow to brute-force compared to an MD5/SHA/CRC, all of which are extremely fast to compute. It's counterintuitive, but the idea is that if Joe Blackhat gets your password hash, he's going to spend orders of magnitude more time chewing on it to get a result than if it were hashed with a fast hashing algorithm. Adding more salt to the hash is going to increase its time-to-crack, but swapping SHA1 for bcrypt gets you a future-hardened algorithm that can be adjusted in responses to gains in computing power.

chime 16y ago
I agree why bcrypt is much, much better. No doubt about that. My question was whether there was something I could do to improve security (even if marginally) on platforms that can't/don't support bcrypt. > bcrypt gets you a future-hardened algorithm that can be adjusted in responses to gains in computing power. How would I be able to change the cost factor overtime? I don't store my user's passwords. Should I just re-bcrypt the bcrypted password using a higher cost and in my login_verify code, take that into account? Or is there something else you can do overtime to raise the cost factor?
- bigiain 16y ago
  "How would I be able to change the cost factor overtime?" One system I built stores the workfactor used to bcrypt the current password un the user table, and allows me to increase the "system workfactor". Every time someone successfully logs in with a lower-than-current-workfactor password hash, it recomputes a new bcrypted hash using the currently known successful login password and updates the users credentials. It means if my user table is ever exposed, all frequently used accounts have up-to-date workfactors for their password hashes, and the "relatively weaker" hashes are for infrequently used (or, in this particualar case, expired subscriptions).

by cheald 16y ago

chime 16y ago

I agree why bcrypt is much, much better. No doubt about that. My question was whether there was something I could do to improve security (even if marginally) on platforms that can't/don't support bcrypt. > bcrypt gets you a future-hardened algorithm that can be adjusted in responses to gains in computing power. How would I be able to change the cost factor overtime? I don't store my user's passwords. Should I just re-bcrypt the bcrypted password using a higher cost and in my login_verify code, take that into account? Or is there something else you can do overtime to raise the cost factor?

bigiain 16y ago
"How would I be able to change the cost factor overtime?" One system I built stores the workfactor used to bcrypt the current password un the user table, and allows me to increase the "system workfactor". Every time someone successfully logs in with a lower-than-current-workfactor password hash, it recomputes a new bcrypted hash using the currently known successful login password and updates the users credentials. It means if my user table is ever exposed, all frequently used accounts have up-to-date workfactors for their password hashes, and the "relatively weaker" hashes are for infrequently used (or, in this particualar case, expired subscriptions).