4 ms·
Their solution is very similar to the mode prescribed by [1] and implemented in [2]. There are actually two problems with bcrypt: - It truncates after 72 ch
by CiPHPerCoder 10y ago
Their solution is very similar to the mode prescribed by [1] and implemented in [2].
There are actually two problems with bcrypt:
- It truncates after 72 characters
- It truncates after a NUL byte
If anyone is dead set on following Dropbox's example, make sure you aren't passing raw binary to bcrypt. You're playing with fire.
Additionally, if you're going to use AES-256, don't implement it yourself. Use a well tested library that either uses AEAD or an Encrypt then MAC construction.
[1]: https://paragonie.com/blog/2016/02/how-safely-store-password-in-2016#why-bcrypt https://paragonie.com/blog/2016/02/how-safely-store-password...
[2]: https://github.com/paragonie/password_lock https://github.com/paragonie/password_lock
- arielb1 10y agonitpick: encrypt-then-MAC is an AEAD construction.
- CiPHPerCoder 10y agoNitpick to counter your nitpick: Not necessarily. It's an AE construction, but not necessarily an AEAD construction. You can have IND-CCA3 security without additional data. The converse is also not necessarily true (i.e. an AEAD scheme could be based on MAC-then-Encrypt and IIRC there are some that are built that way), but that's a less useful counterpoint. The recommended AEAD constructions (AES-GCM and ChaCha20-Poly1305) are EtM.
- warbiscuit 10y agoNot sure I understand the purpose of a MAC in this case. What benefit does it provide to hash storage? If the attacker has write access to your database to tamper with the hash, they will mostly likely also be able to sign up as a user, and clone that (properly signed + encrypted) hash over to whichever account they want to log into. When cracking the hash, they'll just ignore the MAC.