Live data from Hacker News

Don't use bcrypt

unlimitednovelty.com

61–70 of 193 posts

Re: Don't use bcrypt

#61
post #20

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 effecti…

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

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?

Re: Don't use bcrypt

#62
post #22
post #19

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…

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

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.

Re: Don't use bcrypt

#63
post #54

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) t…

Ladies & Gentlemen, Moxie Marlinspike, whose comment should be heading up this whole thread.

Re: Don't use bcrypt

#64
post #20

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 effecti…

Isn't that a self-fulfilling prophecy? If you buying into the "just use bcrypt" idea, how will scrypt ever change the fact that it's not widely available on the web?

Re: Don't use bcrypt

#65
post #59
post #27

Earlier quoted context omitted.

"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 t…

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

Pretty much.

Re: Don't use bcrypt

#66
post #22
post #19

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…

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

The reason I would prefer it is that PBKDF2 is standardized in an RFC with proper test vectors an a reference implementation in C.

Bcrypt and Scrypt do not. We could debate the relative quality of the cryptographers behind them all day, but realistically Bcrypt has had at least one widely-deployed implementation bug that caused a real decrease in strength which can be traced back to a lack of proper test vectors.

Re: Don't use bcrypt

#67

> 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 m…

That attitude is abrasively condescending. Why not just say, "people who spent a lot of their time studying cryptography strongly recommend this approach. They feel the approach that you are considering is simply insecure."? Framing things in terms of intelligence isn't going to win anyone over, if that's your goal. And it probably isn't accurate, either.

He's probably using "smart" in the sense of "accumulated knowledge in a particular space" instead of in the sense of raw mental horsepower. http://news.ycombinator.com/item?id=3583985

Re: Don't use bcrypt

#69

> 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 m…

That attitude is abrasively condescending. Why not just say, "people who spent a lot of their time studying cryptography strongly recommend this approach. They feel the approach that you are considering is simply insecure."? Framing things in terms of intelligence isn't going to win anyone over, if that's your goal. And it probably isn't accurate, either.

By all means, use different wording when passing this message along if you're worried about hurting the recipient's fee-fees. But you won't be doing them any favors if you change the message to a Stuart Smalley-style "You can do it! You're good enough! You're smart enough! And gosh darn it, people like you!" Because on this specific subject, the odds are very, very, very unlikely that they actually are.

Re: Don't use bcrypt

#70

> 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 m…

One more example: pseudorandom number generation (non-cryptographic). There are lots of algorithms out there, and lots more you could design, but the Mersenne twister has pretty much become the first-choice algorithm.

Especially with linear congruential generators, it's easy for people who don't know what they're doing to add "extra randomization" that makes the resulting numbers worse than the originals.

It's better for most people to not get fancy and use the standard algorithm.

Post reply on HN