Hacker News Reader

Comment by Xk | Hacker News Reader

No. Use Bcrypt. Always.

Bcrypt is backed by Blowfish, designed by Bruce Schneier. Go look it/him up. It's secure.

MD5/SHA1/etc are not weak because they are cryptographically weak (though some are), it is weak because they are fast. SHA3, when it is picked, will still be a very bad choice because it too will be fast.

So, why Bcrypt? Well, it uses Blowfish. Blowfish has a very slow key scheduling algorithm which basically involves a lot of hashing to get the round subkeys. Bcrypt makes this even slower. So what? Well, with Bcrypt you could set it up to take .3 seconds to verify a password. Try bruteforcing on that.

View on HN

Indeed. Blowfish is also standardized and has withstood peer review, cryptanalysis and has otherwise been baptized by fire. Plus, if it's good enough for people as picky as Theo DeRaadt, it's probably good enough for you.

Bcrypt is backed by Blowfish, designed by Bruce Schneier. Go look it/him up. It's secure.

Well, yes, I trust the Blowfish cipher (and GP probably does too). The question is how we can be sure it isn't being somehow misapplied, i.e. whether the way bcrypt uses it opens some other hole. That's what I (and probably GP) would like to see an expert weigh in on.

Bcrypt is recommended by all the relevant experts who haven't heard of scrypt(1). Those who have(2), use scrypt because it's got a better built-in Moore's Law-defeater than bcrypt.

(1) http://news.ycombinator.com/item?id=601408

(2) http://www.chromium.org/chromium-os/chromiumos-design-docs/p...

True. But this article was about Bcrypt, so I'm writing that instead of Scrypt.

Edit: I defer to tptacek.

(a) Virtually nobody has heard of scrypt; contrary to HN conventional wisdom, Colin is not yet a world-famous cryptographer. Give him time.

(b) There are operational reasons not to use scrypt, one of them being that there is no reference implementation with broad language bindings.

(c) The specific improvement scrypt makes over bcrypt is not yet relevant; nobody has ever hardware-optimized a bcrypt cracker, and the project that successfully does so and publishes their results will have made a contribution to cryptography literature.

(d) Even when bcrypt starts to face down hardware crackers, it doesn't "lose"; you simply have to increase work factors to compensate.

(e) You don't even have to use bcrypt; you can use PBKDF2, which simply iterates SHA1 a tuneable number of times. Bcrypt is better than PBKDF2, but every adaptive hash, PBKDF2 included, is in a different and better league than "salted hashes".

The specific improvement scrypt makes over bcrypt is not yet relevant; nobody has ever hardware-optimized a bcrypt cracker, and the project that successfully does so and publishes their results will have made a contribution to cryptography literature.

Sure they have. A hardware-optimized bcrypt cracker is called a GPU. I can buy a 480-core GPU on Newegg for $350, but it doesn't come with any more RAM than a low-end PC does.

URL to the source code, please.

I am looking right now at Schneier's reference implementation of the Blowfish key setup function, and there is nothing in it that would not be straightforward to parallelize across a CUDA warp (read: no conditional branches). Is it your assertion that getting from here to a working bcrypt cracker would be sufficiently difficult as to constitute a significant "contribution to cryptography literature"?

You win this time, Franke. This time.

Are you earnestly conceding, or are you just bogged down in enough other arguments that you don't want to deal with this one?

I'm earnestly conceding.

What it means to "open a hole" or what a "hole" would even be are hard to imagine in the case of bcrypt.

First of all, none of this security even comes into play until after your password file is stolen, but your and jim's comments imply you believe that using bcrypt would somehow make an existing site less secure.

Question, I use SHA512 for my passwords; is that also "fast" in comparison to bcrypt?

SHA512 is very, very fast compared to Bcrypt. It's only slightly slower than SHA1 or SHA256.

Source: http://www.cryptopp.com/benchmarks.html

Thanks for the answer and the link. My salting algorithm is very strong but I hadn't considered the idea of renting a bunch of EC2 instances and brute-forcing hashes because the hashing algorithms are so fast.

What do you mean by "my salting algorithm is very strong"?

Instead of just concatenating a salt to the password string, I use a dispersion method. I first concat the salt to the beginning of the password and SHA512 that. I then have a globally configured list in my app (it's different for every app I produce) that defines at which index, in the hashed salt+password digest, chunks of the (same) salt are sliced and interspersed.

Given the same list of indexes, I can then "find" the salt of a stored password hash and run a given plain text password through that algorithm.

But, as has been stated, that effort is completely null if the SHA512 algorithm is fast and brute-forcing it only takes a handful of rented GPU instances...

[EDIT] Now that I think about it, if the Gawker attack were to happen to me, then the attackers would also have the source code and can get the salt dispersion list... So this is, in hindsight, kind of pointless.

Poor mans solution here is to iterate your fast hash a number of times.

This is essentially what bcrypt does for you anyway (in a really crude sense).

You shouldn't get downmodded for a comment that demonstrates exactly the moment of enlightenment Coda was trying to get people to have about password hashing. Let me fix that for you.

If I can believe this ( http://www.cryptopp.com/benchmarks.html ), SHA-512 can still hash data at tens to hundreds of megabytes per second on a single couple-year-old core. Bcrypt lets you configure the slowness of your key generation with a "work factor", so I suppose with a work factor of 1 it'd probably be pretty fast too, but with a work factor of 10 it takes me roughly 100ms to hash 1 10-byte password.

So yeah, SHA-512 gives you a much larger keyspace, which is awesome, but isn't demonstrably slower than MD5, SHA-1, etc. Which was one of its design goals (and also one of the goals of all entrants in the ongoing SHA-3 competition).

The question is not whether BCrypt is backed by Blowfish, the question is whether BCrypt uses Blowfish in a way which is cryptographically sound. If it does not, then an attacker may not need to use brute force. Assuming the author has read more of Mr. Schneier's book than the quoted preamble, he should know this -- Schneier discusses this at length in both editions of Applied Cryptography.

Again, an example of this is the 3DES encrypt/decrypt/encrypt process vs. a more naive encrypt/encrypt/encrypt process. One is substantially stronger than the other. One is a secure way to use DES, and one is not.

Bcrypt has been around for ten years. No one has broken it yet. Is this perfect? No. But then again, we don't know that the implementation you would pick for MD5, SHA1, etc are perfect either. You take the best you can get.

Don't use DES-EDE.

Schneier all but disavowed _Applied Cryptography_ in _Practical Cryptography_.

Schneier's reputation as a cryptanalyst is, as even he might concede at this point, somewhat outstripping his actual career.

Bcrypt is part of the academic literature; the people who wrote it are both renowned.

You can make your same critique about any other crypto construction; maybe the OCB block cipher mode is unsafe! After all, Bruce Schneier didn't write it!

You're speculating about the existence of a flaw which is there no evidence to believe could exist. Just because some crypto constructions are not as sound as naive theory suggests does not mean all constructions are flawed, or even capable of being flawed.

bcrypt is not an encryption algorithm. It doesn't "protect" your users' data, so there's no reason to trust or not trust it with their data.

Yes there is. A hash function does protect a user's password.

If you don't believe me, consider this hash function

H(A) = (A>>1)&0xFFFFFFFF

There. Hash function. It sends any input to a 32 bit value. Would you use it for your password though? No. I certainly would not.

Granted, that is an incredibly weak example, but it's one that's easy to see why it's weak, and thus why a hash function does protect a user's data.

ok, that's a fair point. i guess i just believe bcrypt does a better job than that. :)

Reply on news.ycombinator.com