
Securely store passwords with bcrypt - acangiano
http://blog.phusion.nl/2009/08/13/securely-store-passwords-with-bcrypt-ruby-now-compatible-with-jruby-and-ruby-1-9/
======
a2tech
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
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
Nice to see scrypt getting discussed:

[http://blog.phusion.nl/2009/08/13/securely-store-
passwords-w...](http://blog.phusion.nl/2009/08/13/securely-store-passwords-
with-bcrypt-ruby-now-compatible-with-jruby-and-ruby-1-9/#comment-9081)

~~~
ionfish
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/>

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

------
newsdog
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?

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

~~~
tptacek
This isn't even an argument; it's just an attempt to troll this conversation.
You've written enough stuff elsewhere on HN that I know you're not this dumb,
and I know you don't actually think people are talking about brute-forcing the
SHA function itself, despite Phusion's poor choice of words.

You and I both know this attack is about running a dictionary of possible
passwords against a stolen password database, and, because you seem smart (if
annoying), I'm pretty sure you also know that attack is lightning fast. You
also seem young, so you might not realize that this attack was the "industry
standard" password cracking mechanism throughout the entire 1990s; it's the
attack that Crack and John The Ripper are based off of. Before the crappy
LANMAN hash, it was the only password attack Unix hackers had available to
them, and it was so effective that every Unix system had to implement "shadow"
passwords.

Please stop trolling, sho.

~~~
sho
tptacek, I am not trolling. If you can show me an instance where anyone, ever,
has successfully brute forced a properly set up (salted AND peppered) hashed
password from ONLY the hash and the salt then I will quite literally eat my
hat. It simply cannot be done with current technology and no amount of rank-
pulling will change that.

However, I've actually changed my mind and conceded defeat on this one. If the
attacker could grab a copy of the app code as well and get the pepper &
hashing setup, bcrypt would indeed slow down the ensuing attack on the
passwords. You're basically screwed by then, of course, but it would be nice
for the users if they had a little while longer to change their passwords on
other sites.

I'll be using bcrypt from now on.

~~~
tptacek
You're not even reading my comment before responding to it. Focus your
attention on the part about how the attack bcrypt defeats was the sole attack
used against Unix passwords for an entire decade, the basis for two of the
most popular security tools of all time, and the reason we have shadow
passwords.

Also, there's no such thing as "pepper", despite what the PHP forums may say.

If you weren't deliberately misleading developers into using insecure code
patterns, I'd just ignore you, sho.

