[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,
http://www.tarsnap.com/scrypt/scrypt.pdf): http://i.imgur.com/iUpUk.png

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
companies store.

> 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
> wrote:

> 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
> implemented.
>
> 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.
> --
> http://www.subspacefield.org/~travis/
> "What are you saying?" "I'm not saying anything. I didn't say anything
> then,
> and I'm not saying anything now." -- Babylon 5
>
> _______________________________________________
> cryptography mailing list
> cryptography at randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20120816/6de81593/attachment.html>


More information about the cryptography mailing list