3 ms·

Cryptographic password hashing functions such as bcrypt have relatively low maximums. Bcrypt sits at 72 characters, which if you used 4-byte UTF-8 is pretty sho

Cryptographic password hashing functions such as bcrypt have relatively low maximums. Bcrypt sits at 72 characters, which if you used 4-byte UTF-8 is pretty short, for example. Bcrypt is outdated but still widely used, I reckon.

throwaway2016a 4y ago
I actually didn't know that about Bcrypt. Good to know! Thank you. Though, 72 (18 if using 4 byte) would still be better than 10. Edit: Also as OWASP suggestions (I thought of it but wanted to verify if it was OK before I posted)... if you're using Bcrypt you could hash it with something like sha256 before running it through Bcrypt to get around the length limit. Edit: mistyped "bit" instead of "byte" :(
wongarsu 4y ago
Wouldn't this be easily solved by giving bcrypt the sha512 of the password? Though 72 or 36 characters max really isn't so bad.
- throwaway2016a 4y ago
  If you check out the Bcrypt section of OWASP[1] this is exactly what they suggest. [1] https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#:~:text=bcrypt%20has%20a%20maximum%20length,be%20enforced%20when%20using%20bcrypt https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor....
  - wongarsu 4y ago
    Interesting, that page links to two problems that can appear: - bcrypt implementations that assume zero-terminated strings, which leads to easy attacks if you feed them raw hashes (1/256 chance that the first byte is 0, so on average every 256th user has a password that has a hash collision with with one in every 256 passwords) - password shucking, which is where the attacker has hash(password) from other breaches (where hash is sha256 or similar), and you use bcrypt(hash(password)) (with the same hash function), which allows the attacker to bcrypt the hashes he has, compare them, and if any match can attack the much weaker hash(password). Which is probably why their version uses `bcrypt(base64(hmac-sha256(data:$password, key:$pepper)), $salt, $cost)`. That seems complicated, bu the base64 encoding avoids the first issue, and the pepper the second. I guess that shows how easy it is to get these things wrong, even if it seems trivial.

throwaway2016a 4y ago

I actually didn't know that about Bcrypt. Good to know! Thank you. Though, 72 (18 if using 4 byte) would still be better than 10. Edit: Also as OWASP suggestions (I thought of it but wanted to verify if it was OK before I posted)... if you're using Bcrypt you could hash it with something like sha256 before running it through Bcrypt to get around the length limit. Edit: mistyped "bit" instead of "byte" :(

wongarsu 4y ago

Wouldn't this be easily solved by giving bcrypt the sha512 of the password? Though 72 or 36 characters max really isn't so bad.

throwaway2016a 4y ago
If you check out the Bcrypt section of OWASP[1] this is exactly what they suggest. [1] https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#:~:text=bcrypt%20has%20a%20maximum%20length,be%20enforced%20when%20using%20bcrypt https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor....
- wongarsu 4y ago
  Interesting, that page links to two problems that can appear: - bcrypt implementations that assume zero-terminated strings, which leads to easy attacks if you feed them raw hashes (1/256 chance that the first byte is 0, so on average every 256th user has a password that has a hash collision with with one in every 256 passwords) - password shucking, which is where the attacker has hash(password) from other breaches (where hash is sha256 or similar), and you use bcrypt(hash(password)) (with the same hash function), which allows the attacker to bcrypt the hashes he has, compare them, and if any match can attack the much weaker hash(password). Which is probably why their version uses `bcrypt(base64(hmac-sha256(data:$password, key:$pepper)), $salt, $cost)`. That seems complicated, bu the base64 encoding avoids the first issue, and the pepper the second. I guess that shows how easy it is to get these things wrong, even if it seems trivial.