Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't use bcrypt

unlimitednovelty.com

Post reply on HN
Print view View original

81–90 of 193 posts

Re: Don't use bcrypt

#81

Post by InclinedPlane »

smacktoward wrote: post #49

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

Option 1: Rely on what everyone else does.

What happens if that method is flawed? You hear about it as soon as it's discovered and it gets fixed quick.

Option 2: Roll your own stack based on a personal understanding of cryptography.

What happens if that method is flawed? Perhaps only you and an attacker could possibly know such a thing. You have to be ever vigilant and you have to acquire an incredible amount of crypto knowledge. If you ever leave the company they are pretty much fucked from then on until whatever you wrote is replaced.

Don't roll your own system.

Re: Don't use bcrypt

#82

Post by tptacek »

SoftwareMaven wrote: post #73

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

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

Re: Don't use bcrypt

#83

Post by sk5t »

dhimes wrote: post #59
tptacek wrote: 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?

See p. 3 here http://www.tarsnap.com/scrypt/scrypt.pdf

Re: Don't use bcrypt

#84

Post by pnathan »

smacktoward wrote: post #49

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

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

I hear that a lot, and it always reminds me of Jante Law[1]. Its a disservice to keep telling people that they are too stupid to understand something. Too ignorant, perhaps - that can be remedied - but everyone is not too stupid to understand crypto. It's simply another field, mostly mathematical, and goof-ups are easy to make and often very costly.

edit: I should also make another point. Cryptography is exactingly and excruciatingly hard to do at industrial strength. I am not recommending people go out and roll their own crypto for production systems. It's possible for the initiated to do right; it's possible to get initiated. The uninitiated almost certainly will goof. I'd like to further point out [2], which is a discussion and break on a homebrew crypto, for a taste of the difficulties and mathematical sophistication needed.

[1] http://en.wikipedia.org/wiki/Jante_Law

[2]http://phrack.org/issues.html?issue=64&id=10#article

Re: Don't use bcrypt

#85

Post by 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".

Re: Don't use bcrypt

#86

Post by bascule »

moxie wrote: 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…

These are all valid criticisms. Apologies for using "cipher" where I meant "algorithm"

Re: Don't use bcrypt

#87

Post by Firehed »

tpsreport wrote: post #56
smacktoward wrote: post #49

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

The point here is that this particular cargo cult around bcrypt (one subscribed to by some really loud people) has a shaky foundation and does not deserve its reputation. He's offering alternatives that have been better studied. So, by all means, subscribe to a cargo cult for crypto. But pick the cult carefully.

He's correct in that if you've selected bcrypt for key derivation, there's a good chance you could be doing things better (for one, its output is only 184 bits long; insufficient for AES256) where PBKDF2 works in a way where you can customize the output length.

However, the point of the bcrypt argument is not that bcrypt is the best algorithm for certain things, but that it's (at a minimum) about four orders of magnitude better than most people's "secure" password storage algorithm: sha1(password). Because it requires both a salt and a work factor, even a dictionary attack is wildly impractical unless there's a massive flaw discovered in the algorithm.

If developers are going to be trained to pick a specific algorithm for password storage, I'd much prefer bcrypt (no known flaws, many benefits) over sha1 or md5 (designed to be fast for checksumming, salt not required). Might PBKDF2 be a better choice still? Very possibly; I haven't done enough research to intelligently answer - and since this is crypto, I will not best-guess it.

My real point here? The article attacks bcrypt as a key derivation algorithm, but I've never seen someone suggest it to be used in such an application. Even the post that started what you may call the bcrypt movement (http://codahale.com/how-to-safely-store-a-password/) is linked in the article, and it's titled "How to safely store a password". It is NOT titled "How to safely derive encryption keys".

So yeah, I'm calling linkbait.

Re: Don't use bcrypt

#88

Post by zobzu »

regularfry wrote: post #61
cperciva wrote: post #24

Earlier quoted context omitted.

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?

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.

Re: Don't use bcrypt

#89

Post by m0nastic »

dhimes wrote: post #59
tptacek wrote: 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?

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

Re: Don't use bcrypt

#90

Post by pbsd »

tptacek wrote: post #80
pbsd wrote: post #62

Earlier quoted context omitted.

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…

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

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.

Post reply on HN