[Owasp-leaders] How to store a password

Marco M. Morana marco.m.morana at gmail.com
Fri Feb 18 18:58:12 EST 2011


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?




 <http://codahale.com/how-to-safely-store-a-password/> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-leaders/attachments/20110218/a6e392dd/attachment-0001.html 


More information about the OWASP-Leaders mailing list