4 ms·
bcrypt has stood the test of time very well. It (unintentionally?) does better than some more modern algorithms which are optimized for the wrong kind of "compu
by e4m2 3y ago
bcrypt has stood the test of time very well. It (unintentionally?) does better than some more modern algorithms which are optimized for the wrong kind of "computational hardness", i.e. cache/memory hard. That being said, to avoid all pertinent issues, it probably should only be used in a construction like: (where `mac` is HMAC, CMAC, the keyed mode of BLAKE etc.)
mac(bcrypt(mac(password, secret_key)), secret_key)
This has the following caveats:
1) The output of `mac` might need to be encoded in an ASCII-clean way, e.g. using base64, as some implementations don't do well with embedded nulls or 8-bit data.
2) `mac` should produce 72 bytes of data or more. Truncating is better than padding.
3) An appropriate cost should be chosen, 12 or 13 seem to be common choices and should provide a large enough security margin.
- NavinF 3y ago> optimized for the wrong kind of "computational hardness", i.e. cache/memory hard You got that backwards. Alternatives like Argon2 are way more expensive for attackers because they can be configured to be memory hard
- tptacek 3y agoThe reason people suggest HMAC or keyed hashes with password hashes is that they believe this foils attackers who steal password databases but not the HMAC key. Of course, that begs a question: if you have a place to store an HMAC key where attackers can't get it, why not just store the password hashes there? In reality: if you've lost your password hash database, your application has been game-overed. You don't hash passwords to further protect your own app; you do it to protect everybody else who is exposed to the inevitably shared passwords that users use. Don't do stuff like this.