[cryptography] any reason PBKDF2 shouldn't be used for storing hashed passwords?
Patrick Mylund Nielsen
cryptography at patrickmylund.com
Wed Aug 15 20:25:34 EDT 2012
PBKDF2 is certainly decent, and often the easiest choice if you intend to
comply with e.g. FIPS 140-2/ISO 27001, but the biggest argument against it
is that it _isn't_ difficult to parallelize, since it is just e.g.
HMAC-SHA256. Each guess might require sequential iteration, but you can
still compute many guesses simultaneously. bcrypt is slightly more
computationally expensive (although its 55-byte input limit is often
ignored,) and scrypt is massively more so, requiring a significant amount
of die area. I don't know of an AKDF that can be tuned to be as expensive
to parallelize as scrypt. Comparison (from the scrypt paper,
If you are building a new system, I would definitely recommend
investigating if there is a good implementation of scrypt for the language
you are using -- library support has been improving recently. But, to be
honest, if you use PBKDF2 with a high iteration count (at least 0.2s per
run on a decent system), your digests are stronger than the ones most
> PBKDF2-HMAC-SHA1 significantly weaker than PBKDF2-HMAC-SHA512?
SHA-1 is still safe in an HMAC construction, however there's no convincing
reason not to use at least PBKDF2-HMAC-SHA256 that I can think of. You
don't need it to be fast. Going beyond that won't really give you much
security compared to using a memory-hard function.
On Thu, Aug 16, 2012 at 1:50 AM, <travis+ml-rbcryptography at subspacefield.org
> Any reason PBKDF2 shouldn't be used for (storing) hashed passwords?
> Seems like it solves many problems:
> 1) slowing down guesses (at cost of slowing valid entries too)
> 2) parameterized iteration
> 3) IV/salt/uniquification
> 4) widely deployed, tested
> 5) difficult to parallelize (iterations)
> 6) prepackaged, doesn't require developers to roll their own
> (and we all know about letting developers roll their own)
> many language stacks
> published test vectors
> 7) No potential short cycles, at cost of being unable to update
> iteration count without preimage
> I'm ignoring the differences between PBKDF2 and bcrypt at the moment,
> I know it seems to require more memory... scrypt seems to be a better
> countermeasure for the FPGA threat, though much less widely
> Also, what's the status of SHA-3? Is it on horizon?
> Finally, is PBKDF2-HMAC-SHA1 significantly weaker than
> PBKDF2-HMAC-SHA512? I couldn't find the latter in JRE
> and some other stacks.
> "What are you saying?" "I'm not saying anything. I didn't say anything
> and I'm not saying anything now." -- Babylon 5
> cryptography mailing list
> cryptography at randombit.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cryptography