2 ms·
>For low-entropy data, you want a hash function that is slow and hard to parallelize. Use a specialized password hashing algorithm like bcrypt, scrypt or Argon2
by SkyMarshal 7y ago
>For low-entropy data, you want a hash function that is slow and hard to parallelize. Use a specialized password hashing algorithm like bcrypt, scrypt or Argon2, and tune it so it’s slow enough without impacting overall usability (e.g. takes 50ms on your server).
For most of the 2010s I've been under the impression that password hashing was a solved problem and that this is the solution.
And yet I still see comments online saying to hash passwords with a salt + 10,000 rounds of PBKDF2. Why bother when you can just b/scrypt it? Is there still some benefit of the former over the latter?
- aaronmdjones 7y agoThere are two principal benefits of sticking with PBKDF2: 1) It's a NIST standard. This may be necessary in some environments, typically just to check a box. (Yeah, I know...) 2) It's necessary for SCRAM (RFCs 5802, 7677), which is a much better login method based on passwords. This is applicable if your system uses GSS-API or SASL (e.g. dovecot IMAP logins). If neither applies, my advice is to migrate to Argon2.
- masklinn 7y agoAlso PBKDF2 is really easy to implement if you have a cryptographic hash (even more so with a ready-made HMAC), which is useful if you can't or don't want to pull in dependencies.