[Owasp-leaders] Password Storage and Hash Chaining

Jim Manico jim.manico at owasp.org
Sun Jul 1 20:53:16 UTC 2012


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


More information about the OWASP-Leaders mailing list