People keep posting this here. But I think http://www.tarsnap.com/scrypt.html should probably be considered the best way to do this today. Google is even using it in ChromeOS.
How To Safely Store A Password
11–20 of 215 posts
Re: How To Safely Store A Password
#12The article claims it takes bcrypt 0.3 seconds to hash a 4 char password on a laptop.
How does a server authenticate users in high volume with bcrypt? ~0.25 secs per auth request might warrant having a separate server just for authentication.
Re: How To Safely Store A Password
#13The article claims it takes bcrypt 0.3 seconds to hash a 4 char password on a laptop. How does a server authenticate users in high volume with bcrypt? ~0.25 secs per auth request might warrant having a separate server just for authentication.
Most of your traffic should be coming from people with logged in cookies. If you make people enter their password on every page, you won't have to worry about high volume. :)
Note that bcrypt is basically insensitive to length of password. 4 chars, 8 chars, 32 chars, all take the same amount of time. And it's tunable. You could go down to only 0.01s per hash and still be a million times slower than plain MD5.
Re: How To Safely Store A Password
#14The article claims it takes bcrypt 0.3 seconds to hash a 4 char password on a laptop. How does a server authenticate users in high volume with bcrypt? ~0.25 secs per auth request might warrant having a separate server just for authentication.
It depends on the work factor. On my dev server (a pretty old machine), with a work factor of 7, it's about 300 time slower than md5 (about 10ms per bcrypt hash). That's still plenty fast, and much more secure. Bump it to a work factor of 9, and I'm looking at about 1000 times slower (or getting close to 40 ms per hash).
Part of its beauty is you can adjust the work factor to match your hardware speed requirements.
If you really want ultra-secure, a work factor is 13 is getting pretty slow (about half a second per hash on my crappy machine), and yeah, that might justify an authentication server.
(note: my tests were not exhaustive)
Re: How To Safely Store A Password
#15the weaknews is actually storing the salt or code or key with the password. using bcrypt helps a bit but doesnt truly solve the issue. i think thats important to point out. sha1 with a salt u cant find beats bcrypt with a key u know any day
Re: How To Safely Store A Password
#16The real question should always be how you detect and handle these attacks. Allowing someone to attack your service for 12 years and eating up your resources in the meanwhile just sounds too passive a solution.
Re: How To Safely Store A Password
#17I have read this article and read the Wikipedia entry on bcrypt and I still cannot understand something. In this article it states that : "As computers get faster you can increase the work factor and the hash will get slower.". How can you make the algorithm slower over time and still be able to validate user passwords that were stored before you changed the speed? Could anyone enlighten me on this?
The easy way is to support the previous work factors and increase it next time the user logs in (since you'll have the password in plaintext in memory). Either way, bcrypt with a paltry work factor of 7 or 8 is orders of magnitude slower than md5 and sha. Jack that up to 12 or 13 and you're pretty much good to go for years, the only problem is the near 1-second processing time on semi-current hardware.
It's a hash function and, at least over an insecure connection, you should not be transferring the plaintext password from client to server so it's not guaranteed that you will have the plaintext password.
Assuming you're using a secure connection and you're willing to send plaintext passwords over it then yes, you could re-hash the password when a user logs in.
Re: How To Safely Store A Password
#18Earlier quoted context omitted.
Not too difficult if it's composed of dictionary words. Why not automatically generate random strings to use? No pattern at all.
with cuda and the cloud it's quicker to try all possible passwords (starting with aaaaaaa...) than to search a rainbow table of dictionary words so ":Hy6&z@z" is now no more secure than "password"
Rainbow tables don't apply to salted passwords.
Re: How To Safely Store A Password
#19Another thread where seeing Karma would really help...
Maybe it should be optional?
Re: How To Safely Store A Password
#20The real question should always be how you detect and handle these attacks. Allowing someone to attack your service for 12 years and eating up your resources in the meanwhile just sounds too passive a solution.
That's not the attack you worry about: instead, consider the case where someone somehow obtains the database and can do an offline attack on it. Be it a SQL injection or account compromise (or sheer negligence and publishing the database), once that happens you'd better handle passwords reasonably well.
If the only attack situation you're worried about is a online guessing attack, then there's no need to even hash passwords.