[Owasp-leaders] [Esapi-dev] How to store a password

Ralph Durkee ralph.durkee at owasp.org
Fri Feb 18 20:52:50 EST 2011


On 2/18/2011 8:00 PM, Jim Manico wrote:
>> Did I miss something? Or maybe your own
>> conclusion? I'm kind of interested in that part, see. :)
> Ok then :) My conclusion is:
>
> Hash ITERATION accomplishes the same thing (slow down the attackers custom rainbow tables) as bcrypt's WORK FACTOR. Either methods works as a decent low-risk password storage mechanism

Using a custom rainbow table on a salted password?   I don't think so,
unless there's a new technique I've missed.  Tell me if I'm wrong?

> So to sum up we need, in my opinion, 4 mechanisms to safely store a password:
>
> 1) Strong hash (bcrypt or sha2(512))
> 2) Utilize hash iterations (sha2) or a work factor (brcypt) to slow down the attacker. Today, I recommend 100,000 iterations of SHA2 (per jsypt); but we should increment that recommended number ever year per moores law (and implementations should be able to do hash migration over time).
> 3) I still think we should use a cryptographically random salt, but I'm not sure what size to recommend. Time to do a little manual math labor soon.
Agree.  I've often recommend 48 bits of entropy for standard needs 
(such as 8 characters x 6 bits per char),  which is a commonly used
value. The point here is to make pre-calculation too expensive to
store.  I could see doubling that as this discussion seems to be well
beyond the industry norms,  but getting more bits has a diminishing
return for the extra storage.

-- Ralph

> 4) I also recommend salt isolation (ie: something along the lines of keeping hashes in DB and salts in a file system or different schema)
>
> Secure Remote Password is new to me, I'll check it out John.
>
> Keep in mind that PBKDF2 handles 1-3 for you. :) http://en.wikipedia.org/wiki/PBKDF2
>
> But then again, we are all moving to multi-factor authN anyhow, right? ;)
>
> Cheers all + thank you,
> Jim
>
>
>
>
>
>> Let's not forget about Stanford's alternative called Secure Remote Password:
>> http://srp.stanford.edu
>> http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol
>>
>> Pretty cool stuff. JavaScript implementation available for client side.
>>
>> Jim, the article you sent did not cover iterated hashing although you
>> mentioned it in your blurb. Did I miss something? Or maybe your own
>> conclusion? I'm kind of interested in that part, see. :)
>>
>>    Regards, John
>>
>>
>> 2011/2/19 Marco M. Morana <marco.m.morana at gmail.com>
>>
>>> I think is a good idea to increase the processing cost still maintaining
>>> compatibility with old password hashes like bycrypt does. This way you do
>>> not need to continuously upgrade algorithms and key lengths such as MD5 to
>>> SHA-1 and SHA-2 to keep up with processing speed, you can keep the same
>>> algorithm and change the “work” factor of the algorithm to catch up with
>>> increased attacker availability of processor performance at reduced cost.
>>>
>>>
>>>
>>> I am not sure how bcrypt compares with SHA1 or 2, the article mentions
>>> about 100 million times faster (from microseconds (10^-6) to tenth of a
>>> second (10^-1) by comparing it with MD5 that is not acceptable by most
>>> encryption standards today.
>>>
>>>
>>>
>>> The problem of adopting bycrypt for hashing is that blowfish is banned by
>>> most business encryption standards (including the FI that I work for) as
>>> well as FIPS-140
>>>
>>>
>>>
>>> Regards
>>>
>>>
>>>
>>> Marco
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From:* owasp-leaders-bounces at lists.owasp.org [mailto:
>>> owasp-leaders-bounces at lists.owasp.org] *On Behalf Of *Jim Manico
>>> *Sent:* Friday, February 18, 2011 5:07 PM
>>> *To:* ESAPI-Developers; owasp-leaders at lists.owasp.org
>>> *Subject:* [Owasp-leaders] How to store a password
>>>
>>>
>>>
>>> I think the convential wisdom to use a SHA-2/salted/iterated hash for
>>> password storage is just wrong. Here is a solid article that discuses why.
>>>
>>> http://codahale.com/how-to-safely-store-a-password/
>>>
>>> Thoughts?
>>>
>>> How To Safely Store A Password<http://codahale.com/how-to-safely-store-a-password/>
>>>
>>> *31 Jan 2010*
>>> Why Not {MD5, SHA1, SHA256, SHA512, SHA-3, etc}?
>>>
>>> These are all *general purpose* hash functions, designed to calculate a
>>> digest of huge amounts of data in as short a time as possible. This means
>>> that they are fantastic for ensuring the integrity of data and utterly
>>> rubbish for storing passwords.
>>>
>>> A modern server can calculate the MD5 hash of about 330MB every second<http://www.cryptopp.com/benchmarks-amd64.html>.
>>> If your users have passwords which are lowercase, alphanumeric, and 6
>>> characters long, you can try *every single possible password of that size*
>>>  in around *40 seconds*.
>>>
>>> And that’s without investing anything.
>>>
>>> If you’re willing to spend about 2,000 USD and a week or two picking up
>>> CUDA <http://www.nvidia.com/object/cuda_home.html>, you can put together
>>> your own little supercomputer cluster which will let you try around
>>> 700,000,000 passwords a second<http://www.win.tue.nl/cccc/sha-1-challenge.html>.
>>> And that rate you’ll be cracking those passwords at the rate of more than
>>> *one per second.*
>>> Salts Will Not Help You
>>>
>>> It’s important to note that *salts are useless for preventing dictionary
>>> attacks or brute force attacks.* You can use huge salts or many salts or
>>> hand-harvested, shade-grown, organic Himalayan pink salt<http://en.wikipedia.org/wiki/Himalayan_salt>.
>>> It doesn’t affect how fast an attacker can try a candidate password, given
>>> the hash and the salt from your database.
>>>
>>> Salt or no, if you’re using a general-purpose hash function designed for
>>> speed you’re well and truly effed.
>>> bcrypt Solves These Problems
>>>
>>> How? Basically, it’s slow as hell. It uses a variant of the Blowfish
>>> encryption algorithm’s keying schedule, and introduces a *work factor*,
>>> which allows you to determine how expensive the hash function will be.
>>> Because of this, bcrypt can keep up with Moore’s law. As computers get
>>> faster you can increase the work factor and the hash will get slower.
>>>
>>> How much slower is bcrypt than, say, MD5? Depends on the work factor.
>>> Using a work factor of 12, bcrypt hashes the password yaaain about 0.3
>>> seconds on my laptop. MD5, on the other hand, takes less than a
>>> microsecond.
>>>
>>> So we’re talking about *5 or so orders of magnitude*. Instead of cracking
>>> a password every 40 seconds, I'd be cracking them every *12 years* or so.
>>> Your passwords might not need that kind of security and you might need a
>>> faster comparison algorithm, but bcryptallows you to choose your balance
>>> of speed and security. Use it.
>>>
>>>
>>>
>>> Feedback appreciated,
>>> Jim
>>>
>>> _______________________________________________
>>> OWASP-Leaders mailing list
>>> OWASP-Leaders at lists.owasp.org
>>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> Esapi-dev mailing list
>> Esapi-dev at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/esapi-dev
> _______________________________________________
> 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: https://lists.owasp.org/pipermail/owasp-leaders/attachments/20110218/6f6b7c71/attachment.html 


More information about the OWASP-Leaders mailing list