
Don't use bcrypt - bascule
http://www.unlimitednovelty.com/2012/03/dont-use-bcrypt.html
======
moxie
This article doesn't feel very well done to me. He writes: "The first cipher
I'd suggest you consider besides bcrypt is PBKDF2."

PBKDF2 is not a cipher. It's a KDF, and it's almost always used with an HMAC
or a cryptographic hash rather than a cipher. The thesis of this article seems
to be "PBKDF2 is well understood, where bcrypt is not." In fact, the opposite
is probably true.

bcrypt uses a block cipher (blowfish) to create its underlying compression
function. Block ciphers are extremely well understood, have been studied to
death for years, and are modeled on extremely well understood constructs. They
can be used to create cryptographic hash functions, but usually aren't,
because they're slow (which we don't care about in this case).

Cryptographic hash functions, by contrast, are not well understood at all.
They are "magic" in many ways, and aren't modeled after anything. Many more
"bad things" happen in this space than in the block cipher space. The only
reason people mess with them at all is because they're faster than block
ciphers, which again, we don't care about in this case.

The other appeal to PBKDF2 is because it "comes from RSA." This doesn't feel
like an extremely compelling argument, but if we were going to believe it,
then why not use the PKCS#12 KDF? PBKDF2 was proposed in PKCS#5, and "12" is a
larger number than "5", so if we're going to do what RSA tells us we should
do, they're essentially saying we shouldn't actually use PBKDF2.

~~~
cdavidcash
_Cryptographic hash functions, by contrast, are not well understood at all.
They are "magic" in many ways, and aren't modeled after anything. Many more
"bad things" happen in this space than in the block cipher space._

Is this a common opinion amongst practitioners? The opposite philosophy (e.g.,
that a random oracle is a "weaker object" than an ideal cipher) underlies some
lines of work in the theoretical cryptography literature.

~~~
pbsd
The two models are equivalent, in fact: <http://eprint.iacr.org/2008/246>

This of course says nothing about how to go about building an actual
cipher/hash that withstands all kinds of cryptanalysis.

Edit: apparently not so clear, I'm told: <http://arxiv.org/abs/1011.1264>

~~~
davidcash
A better interpretation of that paper is that it is giving an upper [edit:
upper bound] on how inequivalent the models are.

Also, that paper was subsequently shown to be fatally flawed.
<http://arxiv.org/abs/1011.1264>

Anyway, yeah, a theoretical diversion.

------
smacktoward
_> I write this post because I've noticed a sort of "JUST USE BCRYPT" cargo
cult... This is absolutely the wrong attitude to have about cryptography._

No. This is incorrect. This is exactly the _right_ attitude for most
developers to have about cryptography, because on a subject as complex as
cryptography most developers (including me!) are _nowhere near smart enough_
to understand the ins and outs.

Encouraging people to make their own decisions on subjects they aren't
equipped to understand fully is dangerous advice. It leads to all sorts of bad
outcomes. People who have to choose between options they don't really
understand end up choosing things at random, or on the basis of incomplete or
misleading information, or getting seized up by the need to make a choice and
choosing nothing at all.

This makes cryptography one of the _very few_ cases where a cargo-cult
approach is better than the alternatives. A simple message that "this is the
approach people smarter than you agree is correct, use it," repeated
consistently, will help more people more completely than dumping them into the
deep end of the crypto pool ever will.

~~~
bascule
You're defending cargo cult cryptography? If you try to use crypto without
understanding it, you're at great risk of using it wrong.

~~~
tptacek
The opposite turns out to be true in practice. People have the choice of using
a simple crypto library interface (like BouncyCastle PGP) or "really getting
to understand" AES, and so end up fielding software with vulnerabilities PGP
addressed in the '90s.

A pithier way to say the same thing is, "you're right, except for the words
'without understanding it'".

------
tptacek
PBKDF2 is worse than bcrypt.

scrypt is better than bcrypt.

bcrypt has the advantage of being both very good, and also broadly available
on web platforms. scrypt does not yet have that advantage; when it does, I
will start saying "just use scrypt".

But the simple fact is: _all three of these functions are fine_. ANY of them
is a huge step forward from what people do without them.

"Just use bcrypt" is 1000x more effective as a meme than "just use adaptive
hashing" (which is what all these constructions are).

So, while I have few specific technical qualms with this article (e.g. why do
I care whether something is a PKCS standard or not?), the overall message is a
bit hyperbolic.

~~~
cperciva
_PBKDF2 is worse than bcrypt._

By roughly a factor of 5.

 _scrypt is better than bcrypt._

By roughly a factor of 4000.

 _why do I care whether something is a PKCS standard or not?_

You don't care, and I don't care, but I'm sure you know lots of companies
which do care (especially since PBKDF2 is a NIST standard too).

~~~
regularfry
When we were looking at password hashing, and the choice came down to bcrypt
or scrypt (about a year ago, so recently enough), I said we should go for
bcrypt because scrypt was comparatively new; inasmuch as it makes a
difference, it's just had less time to be attacked.

Was I wrong?

~~~
zobzu
its a sane decision. just make sure you implement properly. like everything
crypto, it will be broken, eventually. but its a safer choice than a new
algoritm.

it reminds me of the vulnerability issues. when apps have no known
vulnerabilities, all is fine. when a new "instant root compromise of any
system" comes out, its omgomgomg. Then its fixed, and all is fine again.

Except that vulnerability was always there. And other ones that are yet to be
public are there too. And many of them are "omgomgomg" material.

Well crypto is the same. We don't have public data on which algorithm are
broken. We just know they will be eventually, by logic or by brute force.

So, take the wise decisions, and don't forget you might eventually need to
update it.

~~~
cheald
This is a naive attitude. Mathematically-secure cryptography with an
implementation that avoids all side-channel attacks is _unbreakable_ , as in,
would take more time than the projected heat death of the universe to brute
force.

That's not to say that all implementations are secure, or that there are not
undiscovered mathematical flaws in common algorithms, but the idea that all
encryption is brute-forcable given enough AWS instances is just plain
incorrect.

~~~
mikeash
How do you know that mathematically-secure cryptography can actually exist?

~~~
willvarfar
This is not related to password hashing algorithms being discussed here, but:

mathematically-secure cryptography was invented in 1882/1917:
<http://en.wikipedia.org/wiki/One-time_pad>

Fun further reading: <http://en.wikipedia.org/wiki/Venona_project>

Also, fun reading: The Code Book by Simon Singh, and Spycatcher by Peter
Wright

------
steveh73
I'm a web developer, so while security is obviously a huge concern, it's not
my main area of expertise. I don't have the knowledge to evaluate the pros and
cons of each cipher, and the situations in which it's appropriate to use each
one.

It would be wonderful if someone with more knowledge of the subject could
throw up a 1-page site with an appropriate security choice (or a few choices
with situations in which each would be more acceptable) for a given range of
situations, to establish a 'sane default', taking into account their
availability on a number of platforms and programming languages.

For example:

    
    
      Need to sign a message? Use HMAC-SHA1
      Need to checksum a file? Use SHA-1
      Need to hash a password? Use bcrypt
      Need to transmit data over a network? Use SSH2
      Need to secure HTTP? Use SSL 1.2 with (these ciphers in order of preference)
      Need to secure home WiFi? Use WPA2-PSK
      Need to encrypt files? Use GnuPG
      Need to do (this type) of encryption? Use CBC. For (this type), use ECB
      Need to create a TrueCrypt volume? Use (this cipher) with (this many) bits.

~~~
chrismsnz
I guess the question is - who do you trust to make these calls?

In this case, the answer probably is OWASP which is a great and often
overlooked resource, contributed to by a lot of experts in the area. They have
a lot of pages in their wiki that address crypto concerns...

<https://www.owasp.org/index.php/Guide_to_Cryptography>

[https://www.owasp.org/index.php/Cryptographic_Storage_Cheat_...](https://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheet)

<https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet>

~~~
tptacek
OWASP is a great resource with a terrible track record for application
cryptography.

~~~
chrismsnz
Whoops, I will stand corrected.

Casting my eye over the recommendations in the pages I linked - yes some of it
seems to be a little behind the times (for instance, adaptive hashing isn't
mentioned once in terms of securing passwords), but none of it seems outright
terrible.

Is this something that the crypto community/experts can come together and
improve the same way as the vuln/exploit security community have made OWASP
what it is?

Or is the real truth that executing proper crypto techniques are simply to
difficult to boil down into a pile of cheatsheets?

------
cperciva
> _While scrypt's cryptographic soundness, like bcrypt's, is poorly
> researched_

I think we may have different notions of what "poorly researched" means.

~~~
zheng
I think he meant it hasn't undergone the same level of public scrutiny. You've
certainly spent ample time researching it, and it's obviously been tested, but
possibly not as much something like AES.

~~~
tptacek
bcrypt is better tested than PBKDF2: far more publicly "testable" systems use
it (bcrypt was the password file format for OpenBSD).

~~~
there
was?

~~~
tptacek
In the sense of "that's where it came from".

------
DanBC
I like this article. But this sentence is odd.

> […] _with an academic pedigree from RSA Labs, you know, the guys who
> invented much of the cryptographic ecosystem we use today._

Appeal to authority fails a little bit when RSA opens random Excel attachments
from unknown untrusted sources - attached to an email that have to be
retrieved from the junk mail folder.

(<http://blogs.rsa.com/rivner/anatomy-of-an-attack/>)

EDIT: As other commentators point out, I am wrong to suggest that anything
coming from RSA Labs is somehow "weak" because someone at RSA fell for a
phishing attack. I do find it odd that a security article suggests "These
people are good; they did 'this thing' which everyone uses". That's not a
great way to approach choosing crypto components. Even experts make mistakes.

~~~
SoftwareMaven
As does ad hominem...

Edit: realized I should probably explain. What an administrative assistant
does in a social engineering attach has nothing to do with the quality of
cryptographic research at RSA. Humans are ALWAYS the weak point in
cryptography.

~~~
yock
No, ad hominem is "You're wrong 'cause you're a jerk." DanBC pointed out that
their opinion might not be as above reproach as is often assumed because of
past lapses in good judgment.

~~~
SoftwareMaven
_Ad hominem is an attempt to negate the truth of a claim by pointing out a
negative characteristic or belief of the person supporting it._ [1]

That sounds pretty much like what happened above. The truth item is whether
RSA's cipher chops can be respected. The negative characteristic is an HR
person succumbing to a social engineering attack. Ad hominem isn't just
calling names.

Let me put it differently: in what way does the HR rep's mistake reduce the
quality of ciphers that have come from RSA?

1\. <http://en.wikipedia.org/wiki/Ad_hominem>

~~~
icebraining
Ad hominem is an attack on the person whose argument you're trying to
disprove. Here, that person is the one who wrote the article, not RSA.

The argument "X is safe because its creator, Y, has a good reputation" can
certainly be refuted by attacking the claim that Y has a good reputation. It's
not an ad hominem.

The fact that the error by the HR person doesn't actually invalidate RSA's
reputation as cryptographers is more a Non sequitur.

------
justin_vanw
I guess it's hip to have an opinion, but JUST USE BCRYPT. It's secure and
available. Don't spend time thinking about it, just use bcrypt, it does
everything you want, move on to something more worth your time.

Unless you're some blogger who needs to generate some page views, then pick
some obscure topic like how to store password hashes and rake muck.

~~~
baq
> JUST USE BCRYPT

multiple things come to mind:

\- Millions Of Flies Can't Be Wrong

\- Citation Needed

\- JUST USE SCRYPT

etc.

------
noonespecial
I wouldn't exactly call "just use bcrypt" a cargo cult. It has had real
benefits to the web dev community because it factors down to "don't store it
in plain text or use MD5 or something".

Several people working on small projects have already come to me and asked me
"what's this bcrypt thing? should I use it here?" I guarantee these folks
would have just stored it plaintext otherwise. So I've directly observed the
mantra making stuff safer. Win.

~~~
tptacek
I strongly agree that when asked by friends what to use, you should think
about _which library is going to be easier for them to use_ , and not try to
think through which construction is "better". That this blog post gets the
real ordering of betterness wrong is tangential to the real problem, which is
that it gets the value proposition of bcrypt wrong.

------
16s
Microsoft uses PBKDF2 for newer domain cached credentials (DCC2). These
password hashes are stored in the registry of Windows clients (laptops and
desktops) and allow users to logon when the domain is unavailable. They use
10240 iterations. It's very compute intensive to crack... roughly 330 guesses
per second. Great article BTW!

Edit: I only post this to add to the examples of who uses PBKDF2 in addition
to what the article lists.

------
orthecreedence
Oddly enough, this article prompted me to setup bcrypt hashing for our
unreleased app. I tend to not follow the tide when it comes to people
screaming on the internet about something. People get highly emotional about
the "next big thing" and defend with every ounce of willpower the decisions
they've made. While I understand this mentality, it can make it hard to be
objective.

Seeing an article where someone disagrees with the buzzing hive mind is always
refreshing for me and made me actually consider, for the first time, that an
algorithm aside from sha1(app_salt + user_salt + password) would be a good
idea.

I did some research and decided that for PHP, bcrypt is the absolute easiest
option to implement. scrypt is too new, PBKDF2 while administratively accepted
has much less info on using it in PHP than bcrypt does.

So while I ultimately ended up disagreeing with the author, the article was
invaluable in the end.

------
jgrahamc
_However, if you're looking for a key derivation function for a new project,
bcrypt is probably not the best one you can pick._

I'm confused. Why would I pick bcrypt as a key derivation function when there
are nice key derivation functions out there that are widely documented?

~~~
lhnn
As stated in the article, a popular stance on Hacker News and Stack Overflow
is "USE BCRYPT". It's chanted to crypto-noobs and webdevs as a simple-to-use
library for password storage that is more secure than MD5/SHA/Whatever
hashing, and with built-in salts.

The whole point of this article is to say that, in fact, there are other
options.

~~~
tptacek
Bullshit. There is one very-well-written article at Coda Hale's site that says
"just use bcrypt", but in discussions of adaptive hashing on HN, people who
know what they're talking about are continuously at pains to vouch for PBKDF2
and scrypt (it helps that one of the people who knows what they're talking
about on this subject is (a) vocal on HN and (b) designed scrypt).

It irritates me that despite going through the effort of vouching for PBKDF2
and scrypt every time this f'ing topic comes up on HN, people still manage to
reduce this issue to another tribal conflict.

And who are these "crypto noobs" you speak of?

~~~
funkah
_Raises hand_

It's important to know what you don't know. And I know enough about crypto to
know that I don't know anything and should listen to people who do.

------
dlitz
I wasn't aware that anyone suggested using bcrypt for key derivation. The
idea, as I understood it, was to avoid writing your own password hashing
implementation. Bcrypt is a complete password-hashing implementation, so use
it, rather than cobbling something together yourself. This is the standard
advice for cryptographic software.

PBKDF2 isn't a password hash: the specification doesn't define a storage
format for iterated, salted password hashes. It's not that hard to invent one
if you already specialize in writing cryptographic software, but most
programmers still shouldn't be doing that. It's just too easy to make mistakes
that go unnoticed until it's too late.

If you insist on using PBKDF2, then I suggest using my PBKDF2.crypt()
implementation at <https://github.com/dlitz/python-pbkdf2>. I'm not a
cryptologist, but I'm the maintainer of PyCrypto, so presumably I can be
trusted to do a better-than-average job of this sort of thing. If people want,
I'll write a proper spec and add SHA256 support with a different algorithm
identifier (the current implementation still uses SHA1).

But really, if you need a password hash, just use bcrypt and get back to
writing the code that actually provides value to your user base and
differentiates you from your competitors. Bcrypt is good enough for now. _This
advice might change in the future,_ so do pay attention, but for now, just use
bcrypt.

------
ceol
So the author says to use PBKDF2 because it's researched and tested better
than bcrypt, and then suggests scrypt as another alternative despite having,
from what I can tell, _less_ research done on it than bcrypt.

The crypto space can be intimidating to your average dev, but almost every app
needs some sort of protection (at least for user information). I think the
author is fair in wanting to push for the "default" to be PBKDF2 instead of
bcrypt, but should he really be advocating a less-tested function in the same
article?

~~~
tptacek
Is there a reason other than branding that you think it's fair to push for
PBKDF2 to be the "default" instead of bcrypt?

~~~
pbsd
To be honest, I don't see why anyone would use bcrypt over PBKDF2, if the
security of the primitives is of any serious concern. I am new here on HN, so
I'm not aware of your arguments on why bcrypt is better than PBKDF2.

As for the "branding" question, would you recommend XTEA or MARS or Threefish
over AES for someone in need of a block cipher? Of course not. Standards are
not always perfect (and many a flaw has been found in standards), but they are
generally beneficial.

PBKDF2 also has the advantage of being modular. It takes in an arbitrary PRF
(although HMAC-SHA1 is the usual); maybe HMAC-SHA1 turns out to be poor for
the job, just plugin a better PRF (hell, you can plugin a provable PRF that
reduces to integer factorization or the elliptic curve discrete log). bcrypt
is just bcrypt --- a seemingly not too peer-reviewed modification of an
ancient cipher, that is not even recommended anymore.

scrypt is better than both, of course. Provable time-memory hardness is great,
and should be made standard.

~~~
tptacek
It takes an arbitrary PRF that is in practice virtually always SHA2, and
practically always a well-known cryptographic hash function. If you're going
to bank on a cryptographic primitive and you have a choice between "cipher"
and "hash function", you pick "cipher".

Also, for lay developers, choosing a crypto construct for its modularity is
like choosing a smoke detector because it allows you to use different
radiological bits in it. _You're not supposed to be messing with those bits_.
The whole point of the package is not to have random developers changing them.

Also, I want you to note something:

You pick AES not because it's a _standard_ but because it's the product of a
contest in which many of the world's best cryptographers competed to design
the replacement to DES. _That's not what PKCS standards are_. A PKCS standard
is simply something that survived a standards group discussion.

~~~
pbsd
I see you've adopted Moxie's argument, block ciphers against hashes. Very
well. The hard part of designing a good hash function is achieving collision-
resistance; one-wayness is easy. In this context, we don't really care about
collision-resistance, since HMAC can be a PRF without collision resistance of
the underlying hash (there was a recent proof by Mihir Bellare) --- this is
why it's still "OK" to use HMAC-MD5, despite MD5 being completely broken
otherwise. The adage that we know much more about ciphers than hashes,
although still mostly true, is an exaggeration at this point in time, where we
have the HAIFA mode, good block ciphers, and soon SHA-3.

I didn't mean to say that Joe the webdev would be choosing the PRF, that's
insane. But whoever providing the (library) implementation would have their
life facilitated by having modular primitives, instead of having to code
another construct from the ground up.

Edit: True, the AES competition was a much higher-profile event. There is an
important difference (this is not a rebuttal, but a remark): AES is a cipher,
PBKDF is a construction. AES has no proof of security, nor hope of one: it's a
purely heuristic security argument. Through models like the random oracle,
however, we could show that the PBKDF construction is secure, if H is secure.
In such a case, there is not as much need for a competition, unless you're
competing for performance or the like. That said, I would _love_ proofs of
security (or show the lack thereof) for PBKDF2.

~~~
tptacek
It's not "Moxie's argument". It's also Schneier and Ferguson's argument from
Cryptography Engineering:

 _Event hough hash functions are used in almost every system, we know far less
about hash functions than we do about block ciphers. This is one of the
failures of the cryptographic community. Compared to block ciphers, very
little research has been done on hash functions, and there are not many
practical proposals to choose from._ †

It is also the reason why we are sponsoring contests to replace SHA2, because
the research horizon for the current generation of cryptographic hash
functions is... ominous.

You're making a noncontroversial statement (ciphers are better studied than
hashes) sound like a controversy. It's not really a controversy. And please
note: I didn't bring "conservatism" into this discussion; the blog post we're
responding to. If you put it to me directly, I'll say bcrypt is more
conservative than PBKDF2/SHA2 (which is what every current PBKDF2 system is
going to end up using). But I didn't write a blog post that says "don't use
PBKDF2".

† _I say this only to make the point that it's not an argument pulled from
thin air or from Moxie comments; something that Schneier commits to writing
is, I mean to say, very likely to represent conventional wisdom._

~~~
pbsd
You're right, I do recall that passage. Apologies if I sounded patronizing.

I tried to be careful with the wording, precisely to avoid making a common-
sense statement into a controversy. Yes, block ciphers are more well-studied
(2012-70s > 2012-80s). My point was that the gap is much smaller now than
(say) when AES was standardized (I wonder, was that passage also in the
"Practical Cryptography" 2003 book?).

As a personal note, I doubt 5-10 years from now SHA-2 will have been
compromised for password hashing (or HMAC), though. It has been remarked
several times during the process that SHA-2 would have made a great SHA-3
candidate, its only major flaw being length extension attacks. The main fear
was that SHA-2 would succumb to the same techniques as SHA-1 and MD5; so far,
that has not been the case (perhaps because everyone is fighting it off with
the SHA-3 candidates).

Of course, I didn't write a blog post either with anything. I don't blog.
Given the choice, I'd give priority to PBKDF2; that's about it. Of course, I'm
not a customer-facing developer, so my worries are different.

~~~
tptacek
No problem. I think you probably know this stuff better than I do. In
practice, I think PBKDF2 really means "PBKDF2/SHA2", and that in 5 years
attacker tools will be most efficient for PBKDF2/SHA2, less efficient for
bcrypt, least efficient for scrypt, and won't address PBKDF2/AES-256-CBCMAC at
all because nobody will know how to code it.

------
emboss
While we agree on the fact that using either of the three can't be a bad
thing, I'd like to give my opinion on why I favor PBKDF2 over bcrypt, and
probably even over scrypt, although I admit the "memory-hardness" of the
latter makes it superior in principle. But still, my reasons for going with
PBKDF2:

It's not just that it's endorsed by RSA, no it's actually the NIST
recommendation for password hashing and I find it rather unfair that people on
this thread turn that against it!

It's the same argument why we generally recommend AES over let's say Twofish
or Serpent. We all agreed here that in crypto it's a good thing to be
mainstream. And being recommended by NIST makes you Justin Bieber, or not?
Standard algorithms may be poor, true, but being a standard has one important
advantage: most of the public scrutiny goes into the standard. Much more money
and fame there. So it's much more likely that the public will get to know
about a flaw in the standard faster than it will get to know about flaws in
non-standard algorithms. And that's why I follow standards - even if it's a
crappy algorithm, I will know immediately when it's broken and I can react by
replacing it right away. The time between an algorithm gets broken and the
fact becoming public knowledge is potentially higher the less common an
algorithm is. And the time in between being broken and being public knowledge
is the most dangerous in my opinion.

I'd like to point out that bcrypt is not equal to Blowfish. It piggybacks on
Blowfish's key setup. But note that it just piggybacks, on top of that it
further extends the original key setup. Blowfish's key setup was probably
never invented to do what bcrypt does now, and the last 30min of googling have
not brought up any papers about bcrypt cryptanalysis. Compare that to HMAC.
Compare that to using PBKDF2 with HMAC SHA-3 when it's out. I'm not saying
that Blowfish or any of its parts are bad, but if not PBKDF2 itself, but then
most certainly its building blocks have received a lot more analysis than
bcrypt or scrypt. With SHA-3 on the horizon the research community knows a lot
more about hash algorithms and there is a lot of research going into these
topics. That's why I personally feel safer with a construction that maybe in
itself has not received more research than the other two alternatives, but
where its building blocks almost certainly have, unless somebody proves me
wrong. And when that happens, I'll stand happily corrected and will use the
next standard.

------
tedunangst
"that won't help you if an attack is discovered which mitigates bcrypt's
computational complexity."

AND you lose control of your database. Even if I had a magic instant bcrypt
reverser, it does me no good if I don't have the hashes. You cannot be
compromised by a bcrypt mistake, it would only make your already existing
compromise slightly worse.

~~~
tptacek
And of course that's a nonsensical argument in favor of bcrypt, as it applies
identically to PBKDF2 and scrypt.

You could use a similar argument to recommend Elliptic Curve over RSA, or RSA
over Elliptic Curve.

~~~
tedunangst
It's not an argument in favor of bcrypt. It's a rebuttal to an argument
against bcrypt.

I have seen several people, whenever this comes up, make the mistake of
thinking that your whole app could somehow be compromised by the wrong choice
of password hash.

~~~
tptacek
I agree that this is a second-tier security issue, as well.

I only got religion about it after reading 100 threads from people bragging
about how they'd designed their custom password hashes with Whirlpool _and_
AES-256; in other words, as a nerd tic.

------
jiggy2011
To be honest, if anybody breaks into your web application it is very unlikely
to be because they broke any encryption. SQL injection or man in the middle
type attacks are far far more likely.

What you need out of an encryption package is in the event of being tested for
PCI compliance or any legal liability investigation into a breach. You need to
be able to say "all of our encryption is done with bcrypt , it's the industry
standard an complies with X Y and Z".

~~~
m0nastic
The debate around secure password storage is sort of orthogonal to initial
compromise of a web application.

The reason that it's important (although as others here have noted, less
important than primary application security concerns) is what areas of attack
are opened up by using insecure password storage "after" an initial
compromise.

This could be something as simple as being a nuisance to users of the system
(having to send out those "our password database was compromised, and we
didn't do a good job of storing them securely, so you should probably change
all of your associated passwords), to something much more serious (using said
insecurely stored passwords to attack your other systems for example).

PCI doesn't really care how you're encrypting your data at rest. I cracked the
password storage from an application once which was literally just a simple
substitution cipher (which was positionally dependent...it was for all intents
and purposes as secure as a newspaper cryptogram puzzle). That application was
PCI compliant.

While "what you need out of an encryption package" might just be the bare
minimum of "cover your ass", that's no reason to settle for insecure password
storage.

------
tzs
Suppose hypothetically you knew everyone using your service used a strong
password. Say they all have good password managers that generate 40 character
random passwords for them.

Is there then any need to do more than a simple salted hash? (Remember, the
hypothesis is that all your users are using strong passwords).

~~~
tptacek
The difference in that (obviously unrealistic) case is (I think?) between a
cost per password of hundreds of thousands of dollars versus high tens of
millions of dollars.

------
SkyMarshal
TLDR: Use PBKDF2 or scrypt instead.

PBKDF2 has had longer public exposure, and also features an adjustable CPU
work factor (though with a lower theoretical safety-to-compute-time than
bcrypt).

scrypt is newer, but features both a CPU and memory work factor (memory-hard
algorithm), and is algorithmically superior to both.

~~~
_delirium
> PBKDF2 has had longer public exposure

I don't know whether or not it's had _more_ public exposure, but I don't think
it's had _longer_ public exposure. Afaik, bcrypt's canonical reference
document is the June 1999 Usenix paper
([http://static.usenix.org/event/usenix99/provos/provos_html/i...](http://static.usenix.org/event/usenix99/provos/provos_html/index.html)),
while PBKDF2's is the September 2000 RFC
(<http://www.ietf.org/rfc/rfc2898.txt>).

~~~
SkyMarshal
Thanks for the reference, didn't realize that, though I think that's what the
article was implying.

------
SoftwareMaven
As long as we've got some smart people hanging around: where does HKDF[1] fit
into this? More specifically, when would you use HKDF over scrypt?

1\. <http://eprint.iacr.org/2010/264.pdf>

~~~
tptacek
_This makes PBKDFs very di fferent than the general-purpose KDFs studied here.
In particular, while passwords can be modeled as a source of keying material,
this source has too little entropy to meaningfully apply our extractor
approach except when modeling the hash function as a random oracle. Also the
slowing-down approach of PBKDFs is undesirable for non-password settings_

~~~
SoftwareMaven
But, as mentioned by @cperciva elsewhere in this thread, generating a key and
creating a password hash are nearly synonymous. Using HKDF for passwords would
be silly, but the more interesting question is: when would you use scrypt for
key derivation in a system?

More to the point: what are the tradeoffs you'd consider in choosing one over
the other?

(Addressed more to @cperciva...) I'm assuming tarsnap uses scrypt as its
actual key derivation function for file encryption and authentication. Why
scrypt instead of something else (and I have faith that it's not "not invented
here" syndrome)?

~~~
tptacek
I'm quoting the actual paper.

~~~
SoftwareMaven
I am aware. I did read it before I posted it.

~~~
tptacek
So you think maybe Hugo Krawczyk is mistaken? :)

Short answer: I think scrypt is an advancement over the class of constructions
HKDF belongs to. If you're picking nits about which function to use, use
scrypt.

------
dchest
Note that scrypt uses PBKDF2 before and after the memory-hard function.

~~~
cperciva
Only as a cryptographic mixing/expansion function. There is no reason to think
that scrypt's security would be any less if the PBKDF2 calls were replaced
with xor.

~~~
dchest
Doesn't it provide more protection against possible flaws in Salsa?

Also, somewhat related question -- what if Salsa core in scrypt is replaced
with BLAKE core (with fewer rounds than in hash), and SHA-2 in PBKDF2 with
BLAKE, thus making it possibly smaller (hardware and lines of code). Will this
work well?

~~~
cperciva
_Doesn't it provide more protection against possible flaws in Salsa?_

In a very theoretical sense, yes. But Salsa would need to be very very broken
in order for that to matter (hence the "no reason to think" comment).

 _what if Salsa core in scrypt is replaced with BLAKE core (with fewer rounds
than in hash), and SHA-2 in PBKDF2 with BLAKE, thus making it possibly smaller
(hardware and lines of code). Will this work well?_

Probably. I proved the security under the random oracle model, but the
property I actually need is approximately "can't be iterated fast", which is a
_far_ weaker requirement.

~~~
dchest
Thank you for your answers.

------
m8urn
Yes, Use Bcrypt. And Scrypt: <http://news.ycombinator.com/item?id=3725284>

------
antihero
I know this may be dumb, but why don't we chain all the algorithms, then if
one is broken the passwords are still secure.

------
lhnn
tl;dr

PBKDF2 and scrypt each have supposed upsides to bcrypt and all the benefits.

PBKDF2: RSA tested and widely used. scrypt: memory hard as well.

~~~
tptacek
"Memory hard" is a serious benefit that scrypt actually has.

"RSA tested and widely used" is subjective, not particularly meaningful, and
in some senses erroneous, and so makes a poor case for PBKDF2.

If people want to seriously push for scrypt as a replacement for bcrypt as the
"default" function, I'll design and print flags and pennants for the movement.
But when people say "use PBKDF2 instead of bcrypt", I think the net effect is
to scare people back to salted hashes, and my general response is going to be
to poke holes in their arguments.

~~~
dhimes
Question: what does "memory hard" mean? Uses lots of RAM to preclude
simultaneous connections running attempts in parallel?

~~~
m0nastic
Correct.

I just spent the past two days sitting in a workshop on "Special-Purpose
Hardware for Attacking Cryptographic Systems" and the most repeating thread
from all of the talks was how to deal with the unique memory limitations of
GPU's and FPGA's when using them to attack crypto. Bandwidth is the largest
one, and specifically the tiny amount of shared memory available to the GPU.

Basically, if you're forced to use "local memory" (which has a huge cost in
transaction time), the amount of operations per cycle you can perform goes way
down, which in some cases can be the difference between an attack taking "2
years" and "until the heat death of the universe".

~~~
marshray
Just to add to that a little: when comparing these functions it's not so
relevant the _absolute_ time consumed; all of them can be tuned to take
whatever amount of time is acceptable on the defender's general purpose
hardware.

The key factor is minimizing the _relative_ advantage that an attacker with
focused resources (such as dedicated hardware) is able to gain over the
defender.

------
user2459
Long story short, if a bcrypt exploit is found, _you'll be sorry_. So use
<http://en.wikipedia.org/wiki/PBKDF2> or <http://www.tarsnap.com/scrypt.html>
instead. They're apparently better tested.

I'm no expert opinion, but seems a bit unnecessary and that bcrypt is still a
perfectly good choice for most password stores.

------
grandalf
How is being from RSA labs an advantage? I'd estimate that it's more likely
that there are government backdoors in RSA crypto than in other variants.

~~~
marshray
For one, it's something the government uses for its own crypto.

Unlike some crypto standards, PBKDF2 is just something too simple and too
user-configurable to be able to hide a meaningful hole in. Given that PBKDF1
was found to be less-than-ideal and depracated in favor of the better PBKDF2,
it would be a very risky proposition to attempt to weaken it in a way that
gave a meaningful advantage to one party over the other.

