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

Jim Manico jim.manico at owasp.org
Mon Feb 21 14:08:12 EST 2011


The point the author is making about salts is that •password brute forcing• (and not rainbow table use: my mistake) is mathematically the same if the salt is known vs. no salt in use at all.

If an insider had the pieces, the hash, the salt, and the hash iteration count, the attacker could spend as little as a few thousand USD on hardware that provides upwards around 100,000,000 or more attempts a second.

Then as Kevin Wall pointed out, the only thing that will save you is password strength.

-Jim Manico
http://manico.net

On Feb 21, 2011, at 2:10 AM, "Dr. Dirk Wetter" <dirk.wetter at owasp.org> wrote:

> 
> Hi Jim,
> 
> the article is not correct IMO.
> 
> As far as SHA1 is concerned: yes, it's dead. NIST and others
> called SHA1 dead 2 years ago as well as Bruce Schneier. Latter
> one because is has a collision weakness:
> http://www.schneier.com/blog/archives/2009/06/ever_better_cry.html .
> Also note, that even SSL is using SHA1 nowadays.
> 
> With CUDA clusters @ EC2 you can probably crack it even cheaper than the
> article is referring to/
> 
> OTOH you always have to balance security with budget and purpose.
> Taking something better than SHA-1 for financial data
> seems to me like one should definitely do that. As for a
> DB supporting CMS one probably would not need go for this.
> 
> SHA2 will be retited at one point that's why SHA-3 is on the way.  SHA2
> family provides more bits (sha512 = 512 bits, sha256= 256 bits) whereas
> SHA1 is 160 bits. Thus the computing  power needed is much higher (see
> Marco's reply). IMHO the
> article is wrong as far as SHA2 is concerned.
> 
> But the author is IMO also wrong on salts. Of course it slows down the
> attack with both precomputed tables and by means of a cuda cluster,
> supposed you have different salts for each password.  If you have a lengthy
> salt and tables for 512 or even 256 bits of hashes, no storage will
> nowadays be able to store rainbow tables for this. And I haven't
> heard of reasonable computing times against SHA2 in a CUDA cluster. So
> today IMHO a salted SHA2 will still provide good protection.
> 
> As for blowfish/bcrypt: It's kind of remarkable as it was started
> back in 1993 and it's still alive. It's a encryption algorithm
> and no hash function as the SHA family (as the author said). And it was
> well  scrutinized during all the years.
> 
> But as others said: I wouldn't jump on blowfish as it is not widely
> embraced. OTOH it cannot hurt for frameworks to provide this as
> an option. But to call SHA2 and even SHA3 dead before it has even
> surfaced sounds like rubbish to /me/.
> 
> 
> Cheers,
> 
> Dirk
> 
> 
> 
> 
> 
> 
> 
> Jim Manico schrieb, Am 02/18/2011 11:07 PM:
>> 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 |yaaa|in
>> 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 |bcrypt|allows 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


More information about the OWASP-Leaders mailing list