[Owasp-leaders] Password Storage and Hash Chaining

Adrian Hayes adrian.hayes at owasp.org
Mon Jul 2 03:45:29 UTC 2012


Hi Jim,

The hashing algorithm you've described is (afaik) perfectly reasonable.
It is similar to PBKDF2 ( https://en.wikipedia.org/wiki/PBKDF2) but with
a system salt. PBKDF2 has the advantage that it's been well reviewed and
used for a number of years and (maybe?) less easy for developers to mess
up. How about something like this?

    hash = PBKDF2('HMAC-SHA-256', user_password + system_salt,
    user_salt, 5000, 160)
    /
    5000 = number of rounds
    160 = output hash length/


I understand PBKDF2 is FIPS compliant
(http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf)
if used with more than 1000 rounds, proper random salt generation, and a
compliant hashing algorithm.

However, PBKDF2 is not a memory hard algorithm. If you can use a memory
hard algorithm you can help remove the GPU cracking advantage (which can
be a big deal, for SHA-1 GPUs are around 60 - 300 times faster depending
on the GPU). I understand bcrypt is memory hard enough to foil GPU base
crackers (for now), or at least I haven't seen one yet (if you know one,
let me know).

There seems to be many reasonable password hashing algorithms and it
seems like ideally you should have these things:

  * A well reviewed/tested algorithm
  * Adjustably high computational complexity
  * Both per user and per system salts
  * Relatively high memory usage (compared to say, SHA-1)

Which I'm not sure you can do while staying FIPS compliant.

Adrian Hayes
OWASP New Zealand Chapter Leader (Wellington)


On 02/07/12 08:53, Jim Manico wrote:
> A lot of people are looking at the password storage cheat sheet due to
> recent breaches.
>
> One of the recommendations we make is regarding "hash chaining" which is
> to repeat the hash algorithm many times to slow down cracking of hashed
> passwords.
>
> Bcrypt does this (and in general is a good choice for password storage),
> but is often not permitted in some organizations due to it's blowfish
> roots.
>
> So when we cannot use B/S-Crypt, we recommend (ie: via ESAPI and the
> Password Storage Cheat-sheet) the use of one of the SHA family of
> algorithms. In addition to hashing we of course recommend salting. SHA
> variants are insanely fast, and to slow down password cracking we
> recommend hash iteration (which is really formally called "Hash Chaining").
>
> One of the big mistakes we have made in ESAPI and in the Password
> Storage cheat-sheet is that we recommend iterating the just the hash.
> There is no cryptographic benefit to this mechanism in the face of large
> rainbow tables, which do indeed exist.
>
> So this pseudo code from ESAPI is a (total) failure in terms of slowing
> down SHA-based password storage:
>
> // rehash a number of times to help strengthen weak passwords
> bytes = hash(user-salt + system-salt + password)
> for (inti= 0; i< iterations; i++) {
>     bytes = hash(bytes)
> }
>
> And the more cryptographically sound way to store a password based on
> SHA is something along the lines of:
>
> // rehash a number of times to help strengthen weak passwords
> bytes = hash(user-salt + system-salt + password)
> for (inti= 0; i< iterations; i++) {
>     bytes = hash(bytes + user-salt + system-salt + password + hash(i))
> }
>
> I advise that the ESAPI team consider strengthening the current Java
> implementation. The cheat-sheet team will make changes to the Password
> Storage Cheatsheet as well in the near future. For more information,
> please read up on the Merkle theorem (Merkle's time-memory trade-off to
> be more specific).
>
> I am admittedly not a cryptographer, or even an applied cryptographer.
> :) Comments are greatly appreciated. I think we have a long way to go as
> a community to clarify the best way to store a password.  John Steven -
> looking forward to the next iteration of your threat model. :)
>
> --
> Jim Manico
>
> Connections Committee Chair
> Cheatsheet Series Product Manager
> OWASP Podcast Producer/Host
>
> jim at owasp.org
> www.owasp.org
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20120702/76afdb69/attachment-0001.html>


More information about the OWASP-Leaders mailing list