3 ms·
Periodic reminder that fast cryptographic hash functions like SHA-x and MD5, even with a non-secret salt (pepper?), are not designed to resist brute-force attac
by ignoramous 5y ago
Periodic reminder that fast cryptographic hash functions like SHA-x and MD5, even with a non-secret salt (pepper?), are not designed to resist brute-force attacks on data as low-entropy as passwords.
Use scrypt [0], bcrypt [1], or argon2 [2], which are key derivation functions (KDF) built on top of pseudo-random functions (PRF) and designed to be slow.
In one interesting example, the Keybase founders deviced an experimental scheme to generate Bitcoin wallet addresses from a passphrase and a salt using KDFs [3], the advantage here being that the wallet then is fully non-custodial (note, there are better ways to implement non-custodial wallets [4]).
[0] https://blog.filippo.io/scrypt-all-the-things/ https://blog.filippo.io/scrypt-all-the-things/
[1] https://codahale.com/how-to-safely-store-a-password/ https://codahale.com/how-to-safely-store-a-password/
[2] https://signal.org/blog/secure-value-recovery/ https://signal.org/blog/secure-value-recovery/
[3] https://keybase.io/warp/ https://keybase.io/warp/
[4] https://github.com/novifinancial/opaque-ke https://github.com/novifinancial/opaque-ke
- ATsch 5y agoAFAIR the reason this database is stored as SHA-1 hashes is because that's what a large amount of the original data dumps contained. Moving to a harder hash would have required cracking all of them first and wouldn't do much more to ensure the database can't be directly used as a password list for attacks.
- ignoramous 5y agoI think you misunderstood me. I meant that developers must use KDFs and not cryptographic hash functions to store user passwords (at least until WebAuthn takes center stage), so that in the event they are pwned and have their db stolen, the brute-force attacks wouldn't be as effective.