4 ms·

> For example, one situation where you want an intentionally slow algorithm is when dealing with passwords. This is true, but there's also more to the story. M

> For example, one situation where you want an intentionally slow algorithm is when dealing with passwords. This is true, but there's also more to the story. Modern password hashes like Argon2 force attackers into a "time-memory tradeoff", to try to reduce the advantage that specialized hardware has over the general-purpose computers that human beings use. I find that a lot of folks have memorized a summary like "slow hashes are good", and that's doubly unfortunate, because 1) like the article says, fast hashes are good, and 2) slow hashes in and of themselves are no longer the best we can do for password security. I often wish that password hashes weren't even called "hashes", because it's just a very different problem that they're solving. > or even just a high number of rounds of SHA-512 Please god no :)

CodesInChaos 4y ago
> or even just a high number of rounds of SHA-512 PBKDF1 (which is just iterated hashing) has the same security as PBKDF2 when used with fixed length salts, and avoids the numerous pitfalls of the latter. Though it's still not as good as bcrypt, scrypt or argon2.
espadrine 4y ago
> I often wish that password hashes weren't even called "hashes" I agree! And same for crypto hash (as in collision-resistant function) vs. “mixer” hash (as in diffuse permutation)[0]. We should make “PBKDF” a more common name. [0]: https://cr.yp.to/salsa20.html https://cr.yp.to/salsa20.html
jolynch 4y ago
>> or even just a high number of rounds of SHA-512 > Please god no :-) Heh I didn't mean it as a recommendation per say, but I'm pretty sure Linux uses repeated SHA-512 on at least some common distros. At least on my Ubuntu Focal machine my /etc/shadow appears to be using SHA-512.