Have I got your attention? It’s a sensationalist title, but this is important and developers/administrators still get it wrong.
This is a companion discussion topic for the original entry at http://blog.tjll.net/please-stop-hashing-passwords/
This is a companion discussion topic for the original entry at http://blog.tjll.net/please-stop-hashing-passwords/
That’s not Stack Overflow.
You mention CPU intensive algorithms and include PBKDF2, and in passing mention Scrypt.
You should also add that PBKDF2 is pluggable in that the central KDF can be whatever you like (not sure you stated what you used), also that as well as being CPU intensive an aspect of memory intensive computation can help prevent hash acceleration on custom hardwares. The tune-able parameters (don’t use the Tarsnap library) if Scrypt can be very memory and cpu intensive. Putting those together you can get an almost ideal KDF that is optimised for memory and cpu on the platform its implemented on and cannot be accelerated in any meaningful way by using custom hardware (ASIC, FPGA, GPU etc).
For an example of this see: https://www.grc.com/sqrl/scrypt.htm which for the SQRL project to eliminate passwords and usernames uses scrypt in an innovative way to get a fixed time derivation to protect the users master identity storage key.
The graph is… interesting. You’re hashing the same data, over and over, increasing the iterations. I’m not sure what you’re trying to achieve here, other than maybe there is a warmed up cache or some other hidden, internal memory mapping that is not present with the KDF graphs.
Instead, I would be much more interested in seeing how many hashes you can compute per second with key stretching on the non-pbkdf algorithms. By default, Debian-based and Fedora-based distributions use 5k key stretching iterations of SHA512 before storing the hash on disk.
IE: If it takes .001538s to compute a single SHA512 hash, then 5k key strretches would yield 7.69s to compute the final hash for a single string. This is much more interesting, as many who store hashed password databases take adavntage of key stretching.
Whoops - spot on LizardBill. I’ve amended the post to reflect your correction.
Very interesting points, I was unaware as to the modular nature of PBKDF2. I’ll be sure to do some reading up on the function. The fact that the central KDF can be swappable would certainly suggest that, paired with scrypt, the key derivation function could be made very resilient. I’ve also heard a few things about Steve Gibson’s SQRL project but had no idea he was leveraging scrypt, thanks for the additional info. 