[Owasp-leaders] Password Storage and Hash Chaining

Abbas Naderi Afooshteh abbas.naderi at owasp.org
Mon Jul 2 03:51:58 UTC 2012

Hi Adrian,

Thanks for the info, it was very informative.
I think using a memory hard algorithm in general is not a good practice, unless we describe it clearly to the people using it.
They might just not like their systems chewing up so much memory for a simple password check.

I'm gonna read through PBKDF2 and update the page accordingly,
Notice: This message is digitally signed, this means that its source and integrity are verifiable.
Certain mail clients would automatically verify this email and present a "signed and sealed" sign, but others might just provide  a downloadable file (smime.p7s), which includes the X.509 certificate and the signature body.
In this case, you can either ignore it or manually verify it. Read more on this at Certified E-Mail with Comodo and Thunderbird at AbiusX.com

On تیر ۱۲, ۱۳۹۱, at ۸:۱۵, Adrian Hayes wrote:

> 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
> _______________________________________________
> 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/b716f0b6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4889 bytes
Desc: not available
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20120702/b716f0b6/attachment.bin>

More information about the OWASP-Leaders mailing list