[WEB SECURITY] Idea: different approach to password hashing

Nuno Loureiro nuno at sig9.net
Fri Jan 31 11:50:12 EST 2014


On 31/01/2014, at 13:15, Paul Johnston <paul.johnston at pentest.co.uk> wrote:

> 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.

I personally prefer the HMAC(secret, salt + password) approach. If an attacker finds a SQLi and gets the DB, he/she first needs to crack the secret (not really feasible today if you have a strong secret). If the site has a LFI then the strength of this approach kind of sucks, but it is the same as a normal hash+salt.

> 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.

If you have throttling well implemented, taking into account different dimensions, then it looks a lot easier to DoS a site based on slow hash functions.

> 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 :-)

The difference is that JS password hashing doesn't add any security per si, what makes the difference is SSL. :)

> Paul
> -- 
> 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
> <ATT00001.html>
> 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 Scheme
> _______________________________________________
> The Web Security Mailing List
> WebSecurity RSS Feed
> http://www.webappsec.org/rss/websecurity.rss
> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
> WASC on Twitter
> http://twitter.com/wascupdates
> websecurity at lists.webappsec.org
> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20140131/c8c22501/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4121 bytes
Desc: not available
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20140131/c8c22501/attachment.p7s>

More information about the websecurity mailing list