[WEB SECURITY] Idea: different approach to password hashing
jim at manico.net
Fri Jan 31 08:40:15 EST 2014
You are right on. bcrypt and the like are reasonable choices for low traffic websites, but can be abusive hits on CPU/L1/L2 caches and are problematic at scale. For bcrypt with work factor 10, it takes about 10 concurrent runs of bcrypt to pin a high performance CPU.
You have a few choices here.
1) Throw a lot of hardware at it. Lots. I've seen a few folks do this. It works but it's expensive.
2) Reduce the work factor and speed up the algorithm. Bad choice. It defeats the purpose of adaptive algorithms.
3) Use an HMAC, proper key storage and rotation, and cryptographic isolation of the HMAC process in a separate service or the like, so your main app server has no access to the HMAC private key.
Several folks critique these assertions. These ideas are backed by John Stevens extensive, nay, I dare say obsessive threat model on password storage. http://goo.gl/Spvzs
Until someone shows me something similar, I'm going with John's very detailed and well thought out advice.
> On Jan 31, 2014, at 8:15 AM, Paul Johnston <paul.johnston at pentest.co.uk> wrote:
> 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.
> 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.
> 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
> 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
> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
> WASC on Twitter
> websecurity at lists.webappsec.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the websecurity