[WEB SECURITY] Idea: different approach to password hashing

Paul Johnston paul.johnston at pentest.co.uk
Fri Jan 31 08:15:52 EST 2014


When storing user's passwords that you need to verify against (but not
use as plaintext) the current state of the art is:

1) Hash the password
2) Use a salt
3) Use a slow hash function - bcrypt, scrypt, etc.

This provides the best possible protection against an attacker who has
stolen the password database. It does not solve other issues like
phishing, malware, password re-use, etc.

BUT there is one remaining problem: the slow hash function can allow a
denial of service attack. A single request burns a lot of CPU. In
practice I don't think this is a major problem, given defences like IP
throttling. But it does deter people from using a higher work factor, to
really get the benefit of slow hashing.

Given the improving performance of JavaScript in browsers, it may now
make sense to do this in the browser. I'm assuming here that the site is
using SSL, so the JavaScript is delivered securely. If you're not using
SSL, then using a slow hash function is unlikely to be a priority for
you. There is at least once JavaScript implementation of bcrypt
(https://code.google.com/p/javascript-bcrypt/). But using this in a
simple way would introduce two problems:

1) The client needs to fetch the salt from the server. This introduces
latency on login and, unless care is taken, can reveal whether a
particular user account exists.
2) If hashing is done purely on the client then the benefits of storing
hashes are lost. At attacker who has stolen the password hashes can
simply login using the hashes.

However, I think there are acceptable solutions to both of those problems:

1) The salt can be generated as hash(server_salt + user_name) - where
server_salt is a random number that is unique to the server, public, and
the same for all users. The resulting hash appears to have the required
properties of a salt.
2) The server should do a single, fast, hash operation on the hash it
receives. As an example: the server stores SHA-256(bcrypt(salt,
password)). The client sends bcrypt(password) then the server applies
SHA-256 and checks the hash. This does NOT allow an attacker to conduct
a fast offline brute force attack. They can do a fast brute force of
SHA-256(password) because password has a limited amount of entropy -
2^50 or 2^60 or so. But a 128-bit bcrypt(password) has entropy or 2^128,
so they cannot readily brute force it.

Now, perhaps this has already been thought of. Perhaps people are
actively using it (although I've never seen it). If so, apologies for
the line noise.

As some background on me, I was pushing JavaScript cryptography 15 years
back as a simple password defence for sites that do not use SSL
(http://pajhome.org.uk/crypt/md5/). This got a bit of a cult following,
but the world has moved on since then, and really any site with a login
should use SSL. But it seems a use for JavaScript password hashing has
returned! I knew it would all along :-)



Pentest - The Application Security Specialists

Paul Johnston - IT Security Consultant / Tiger SST
Office: +44 (0) 161 233 0100
Mobile: +44 (0) 7817 219 072

*We're exhibiting at Infosecurity Europe!
Stand K97, Earl's Court London - 29th April - 1st May*
Infosecurity Europe 2014

Email policy: _http://www.pentest.co.uk/legal.shtml#emailpolicy_
Registered Number: 4217114 England & Wales
Registered Office: 26a The Downs, Altrincham, Cheshire, WA14 2PU, UK
Accreditations: ISO 9001 (44/100/107029) / ISO 27001 (IS 558982) / Tiger

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20140131/baa98dcc/attachment-0006.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20140131/baa98dcc/attachment-0007.html>

More information about the websecurity mailing list