6 ms·

Securely store passwords with bcrypt

23 points by acangiano 17y ago

a2tech 17y ago
Very interesting stuff here-I've never heard of anyone using bcrypt for encrypting passwords, but it seems like a good solution. The only problem that I see for large implementations is that even with the lowest time setting on bcrypt you're introducing at LEAST a second delay every time someone logs in while you generate the hash. And even on his MacBook Pro he was only able to generate a few hashs per second-if you ever have a rush of signups your potential users could see quite the delay while submitting their passwords.
- tptacek 17y ago
  If you're introducing a 1-second delay for login, and that's not what you wanted, you're doing it wrong. The point of bcrypt is that it's tunable, and its defaults are nowhere near that slow. You do not need to slow hashing down to user-perceptable time to make dictionary attacks infeasible. Also, bcrypt is pretty much the de facto industry standard adaptive password hash. It's not Phusion's crazy idea. There's a PKCS function that works on similar principles (PBKDF), but it isn't as resilient as bcrypt is.
mattyb 17y ago
Nice to see scrypt getting discussed: http://blog.phusion.nl/2009/08/13/securely-store-passwords-with-bcrypt-ruby-now-compatible-with-jruby-and-ruby-1-9/#comment-9081 http://blog.phusion.nl/2009/08/13/securely-store-passwords-w...
- ionfish 17y ago
  There's a small Ruby binding for Scrypt available on GitHub. All it needs is for someone put the time into making it a gem, and maybe bundling it with Scrypt as a Ruby extension. http://github.com/coderrr/scrypt-ruby/ http://github.com/coderrr/scrypt-ruby/
  - FooBarWidget 17y ago
    That's a binding alright. But it's not easily installable: one has to install the scrypt library manually. I'm not sure how to do that because last time I checked scrypt is a program. Scrypt is also not packaged by Debian at this time. All in all, I think it's not the right time to use scrypt yet - at least not until there are easily installable libraries.
sho 17y ago
I don't think this is necessary. SHA1 was designed to be fast, yes - and fast is exactly what you want when you're logging thousands of users into a web site. But that's not even the problem. Security is all about the weakest link. There is no point dialing one of the links up to absolutely insane heights without taking commensurate measures with the rest of your links - and a salted, hashed, SHA1 password is already pretty freaking secure. Let me give an example. If your opponent possesses the incredible resources necessary to brute force SHA1 in a useful timeframe - and there are probably only a handful of such organisations on earth, all governmental - then they will not even bother with that. They will simply bug your server and collect the passwords plaintext somehow there. Or they'll subpoena you and force you to start collecting the plaintext. Hell, what do they need the passwords for anyway? See what I mean? It's solving the wrong problem. Anyone who could actually brute force SHA1 is such a formiddable opponent that they could not care less if you changed to bcrypt or whatever. You have already lost if they even decide to mess with you. Plus, it's yet another dependency. And then the speed penalty. Forget it. Put the time into setting up SSH keys or turning off root login or something; you're a million times more likely to be compromised by those kinds of everyday flaws than NSA-level shit like this.
- iigs 17y ago
  I strongly disagree. What web site has ever been without scaling problems if it weren't for that darn password hash complexity issue? IMO this is really _NOT_ something to optimize for. Consider, most users of web sites have pretty simplistic passwords. The salt needs to be known in order to validate the password, probably stored in the row with the password. If the password database is ever compromised, it's then trivial for an interested party to start pounding salts and hashes through something like http://nsa.unaligned.org/ http://nsa.unaligned.org/ or a botnet of compromised machines.* Sure security might be about the weakest link, but you also have to look at the value of each loss. You're opening yourself up to a firestorm of embarrassment if your user table is leaked (so your argument about securing everything else is important) but that's so much worse when decrypted passwords are going around with the table. [*] The winners of the Engine Yard SHA1 challenge http://www.win.tue.nl/cccc/sha-1-challenge.html http://www.win.tue.nl/cccc/sha-1-challenge.html did almost 700 MILLION SHA1 hashes per second on two beefcake video cards.
newsdog 17y ago
Ok so what happens if my site gets popular - and I can dream, can't I? - and I get hundreds of people logging on per second?

23 points by acangiano 17y ago

Very interesting stuff here-I've never heard of anyone using bcrypt for encrypting passwords, but it seems like a good solution. The only problem that I see for large implementations is that even with the lowest time setting on bcrypt you're introducing at LEAST a second delay every time someone logs in while you generate the hash. And even on his MacBook Pro he was only able to generate a few hashs per second-if you ever have a rush of signups your potential users could see quite the delay while submitting their passwords.

tptacek 17y ago
If you're introducing a 1-second delay for login, and that's not what you wanted, you're doing it wrong. The point of bcrypt is that it's tunable, and its defaults are nowhere near that slow. You do not need to slow hashing down to user-perceptable time to make dictionary attacks infeasible. Also, bcrypt is pretty much the de facto industry standard adaptive password hash. It's not Phusion's crazy idea. There's a PKCS function that works on similar principles (PBKDF), but it isn't as resilient as bcrypt is.

mattyb 17y ago

Nice to see scrypt getting discussed: http://blog.phusion.nl/2009/08/13/securely-store-passwords-with-bcrypt-ruby-now-compatible-with-jruby-and-ruby-1-9/#comment-9081 http://blog.phusion.nl/2009/08/13/securely-store-passwords-w...

ionfish 17y ago
There's a small Ruby binding for Scrypt available on GitHub. All it needs is for someone put the time into making it a gem, and maybe bundling it with Scrypt as a Ruby extension. http://github.com/coderrr/scrypt-ruby/ http://github.com/coderrr/scrypt-ruby/
- FooBarWidget 17y ago
  That's a binding alright. But it's not easily installable: one has to install the scrypt library manually. I'm not sure how to do that because last time I checked scrypt is a program. Scrypt is also not packaged by Debian at this time. All in all, I think it's not the right time to use scrypt yet - at least not until there are easily installable libraries.

sho 17y ago

I don't think this is necessary. SHA1 was designed to be fast, yes - and fast is exactly what you want when you're logging thousands of users into a web site. But that's not even the problem. Security is all about the weakest link. There is no point dialing one of the links up to absolutely insane heights without taking commensurate measures with the rest of your links - and a salted, hashed, SHA1 password is already pretty freaking secure. Let me give an example. If your opponent possesses the incredible resources necessary to brute force SHA1 in a useful timeframe - and there are probably only a handful of such organisations on earth, all governmental - then they will not even bother with that. They will simply bug your server and collect the passwords plaintext somehow there. Or they'll subpoena you and force you to start collecting the plaintext. Hell, what do they need the passwords for anyway? See what I mean? It's solving the wrong problem. Anyone who could actually brute force SHA1 is such a formiddable opponent that they could not care less if you changed to bcrypt or whatever. You have already lost if they even decide to mess with you. Plus, it's yet another dependency. And then the speed penalty. Forget it. Put the time into setting up SSH keys or turning off root login or something; you're a million times more likely to be compromised by those kinds of everyday flaws than NSA-level shit like this.

iigs 17y ago
I strongly disagree. What web site has ever been without scaling problems if it weren't for that darn password hash complexity issue? IMO this is really _NOT_ something to optimize for. Consider, most users of web sites have pretty simplistic passwords. The salt needs to be known in order to validate the password, probably stored in the row with the password. If the password database is ever compromised, it's then trivial for an interested party to start pounding salts and hashes through something like http://nsa.unaligned.org/ http://nsa.unaligned.org/ or a botnet of compromised machines.* Sure security might be about the weakest link, but you also have to look at the value of each loss. You're opening yourself up to a firestorm of embarrassment if your user table is leaked (so your argument about securing everything else is important) but that's so much worse when decrypted passwords are going around with the table. [*] The winners of the Engine Yard SHA1 challenge http://www.win.tue.nl/cccc/sha-1-challenge.html http://www.win.tue.nl/cccc/sha-1-challenge.html did almost 700 MILLION SHA1 hashes per second on two beefcake video cards.

newsdog 17y ago

Ok so what happens if my site gets popular - and I can dream, can't I? - and I get hundreds of people logging on per second?