Do any security experts recommend bcrypt for password storage?

views:

173

answers:

+4 Q:

Do any security experts recommend bcrypt for password storage?

On the surface bcrypt, an 11 year old security algorithm designed for hashing passwords by Niels Provos and David Mazieres, which is based of initialization function used in the NIST approved blowfish algorithm seems almost to good to be true. It is not vulnerable to rainbow tables (since creating them is too expensive) and not even vulnerable to brute force attacks.

However 11 years later, many are still using SHA2x with salt for storing password hashes and bcrypt is not widely adopted.

What is the NIST recommendation with regards to bcrypt (and password hashing in general)?
What do prominent security experts (such as Arjen Lenstra and so on) say about using bcrypt for password hashing?

+4 A:

bcrypt uses blowfish as a message digest function. Blowfish is very old and has been replaced by twofish, thus bcrypt should not be used on a modern system.

As an accomplished cryptographer I recommend using a salted sha256. Sha256 is one of the NIST recommended message digest functions and should be used until until sha3 is finalized. (Skien for the win!)

Rook 2010-09-16 00:32:54

@Rook For a web application, is it worth it to repeat the hashing some number of times (to do a bit of stretching, but not so much that it will annoy the user)? Or does that not really add anything?

Andy 2010-10-11 18:01:19

@Andy Stretching is useful when the attacker will always have access to the hash or it is used a string2key function. If you look at the PBKDF2 wikipedia page you'll see that this is used in encrypted file systems and encrypted archives. In order to get any real benefit you must do many thousands of iterations and this is simply out of the question in a web app setting where you can have thousands of people logging in at any given moment. try an `openssl -speedtest` on your system to get an idea.

Rook 2010-10-11 18:04:47

@Rook Thank you!

Andy 2010-10-11 18:06:43

@Andy your welcome :)

Rook 2010-10-11 18:10:22

+4 A:

bcrypt has a significant advantage over a simply salted SHA-256 hash: bcrypt uses a modified key setup algorithm which is timely quite expensive. This is called key strengthening, and makes a password more secure against brute force attacks, since the attacker now needs a lot more time to test each possible key.

In the blog post called "Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes", which I personally recommend you to read, Thomas Ptacek, the author and a security researcher recommends the usage of bcrypt.

Personally, I've been looking at PBKDF2 lately, which is a key derivation function that applies a pseudo-random function (e.g. cryptographic hash) to the input password along with a salt, and then derives a key by repeating the process as many times as specified. Although it's a key derivation function, it uses the principle of key strengthening at its core, which is one of many things you should strive for when deciding on how to securely generate a hash of a password.

To quote Thomas Ptacek from the above linked post:

Speed is exactly what you don’t want in a password hash function.

Giu 2010-09-16 07:39:01

I read that blog post earlier today, thought it was very good. +1

Coronatus 2010-09-16 07:46:09

For the record this is not suitable for web applications. PBKDF2 is used on encrypted files systems. Also this is a terrible trade off of resources in terms of security. Efficiency is very desirable in an authentication system. Also, you can layer any message digest, it doesn't matter if its built from a block cipher.

Rook 2010-09-16 07:54:00

@Rook that's the reason why I mentioned that it's a key derivation function; I use it in combination with a symmetric key algorithm currently. The point of my reply was to show why bcrypt is better than a salted SHA-256 hash (1 round); *key strengthening* is the keyword here. You can use key strengthening for user authentication in web applications, too, although you should use a lower number of rounds, since the user actually doesn't want to wait 10 seconds for the login to happen.

Giu 2010-09-16 07:59:24

@Rook but, I wouldn't say that PBKDF2 is not suitable for web applications, since another application of the standard is in message authentication. I personally wouldn't completely dismiss PBKDF2 in this case. But then again, I'm no security expert.

Giu 2010-09-16 08:13:44

I have seen Thomas Ptacek article around, and I have no doubt he is a pretty accomplished cryptographer I should have cited it, however he seems to be the main force pushing for this. My main question here is not "why is bcrypt or scrpyt for that matter better than a simple salted password" but rather, what is NIST / Arjen Lenstra / Bruce Schneier and other prominent figures recommendation on this issue.

Sam Saffron 2010-09-16 08:20:16

@Sam Saffron that is a very good question i have tried to see Bruce Schneier's view on the topic, but I haven't been able to find it.

Rook 2010-09-16 18:56:48

@Giu It is unsuitable for web applications like SO or to a greater extent OpenID, there are thousands of people logging in at any given moment and its already difficult for the server farm to keep up. Its a matter of logic, if your trying to make it too heavy for the attacker to lift then its too heavy for your servers to lift. By contrast PBKDF2 is implemented in areas where only an individual or a handful of people are authenticating at any given moment (siting the wikipedia article on PBKDF2).

Rook 2010-09-16 18:58:19

@Rook I saw and see your point; the process eats up quite some resources, and with a huge user base, you probably don't have *spare* resources to authenticate a user in that way. I'd say for web applications, salting a password's hash generated by a cryptographic hash function from the SHA-2 (or SHA-3 some time in the future) family surely is a good way to go currently. And an environment with a handful of people is surely a better

Giu 2010-09-17 06:25:43

@Giu thank you for seeing my point.

Rook 2010-09-17 06:26:38

@Rook No problem. My only question now is: why does Thomas Ptacek write in his article that this form of password check is *negligible*? bcrypt surely is different from PBKDF2, but both use a number of iterations to generate the resulting bytes, and this process surely eats up some resources. So why is this negligible when tens of thousands of logins occur per hour? Only because it makes a small proportion of the time (or resources) used for other occurrences, like database hits, page refreshes, and IO?

Giu 2010-09-17 06:32:26

@Giu I honestly don't know know who Thomas Ptacek is, I have read that same article and I think he is mistaken. Why an "accomplished cryptographer" suggesting to use a deprecated primitive? No one should use blowfish. Even this idea of doubling the cracking time is rather absurd. On an a dual core Intel doing a `openssl speed` command i can do about 100,000 sha256() hashes of an 8 char password in a second. So thats every English word in about 4 seconds, give or take. If you double that time then its only 8 seconds. To have any real effect you need a few thousand iterations.

Rook 2010-09-17 06:49:27

@Rook Thanks for your answer. Yes, it only has a real effect if you specify a big number of iterations; the MD-5 scheme of `crypt` for example is broken because it uses a fix number of iterations, which is too small, and therefore isn't computationally expensive anymore. It would be interesting to know why Mr. Ptacek has written that passage in the article; it's difficult to imagine that the resources spent for this password scheme are all that negligible on a high traffic server. Maybe I'll write him a mail regarding this; I'm interested in hearing his opinion.

Giu 2010-09-17 07:08:14

As far as I can tell, Rook's objection to both bcrypt and PBKDF2 is that they are (by design) expensive, and this can be turned into a DOS attack. That's certainly true, but it's not as if DOS attacks aren't a problem already, or as if throttling is unable to defend against this particular attack. So, in the end, I'm really not sure what the argument is. *scratches head*

Steven Sudit 2010-09-18 02:10:37

@Steven Sudit, regarding my reasoning mentioned in your answer: I'm all for PBKDF2, but I don't know if somebody's really using it to authenticate users of a web application, because of the resources it'll eat up depending on the number of iterations defined; this may hurt the usability, and it'll annoy the user as a result (long waiting time). I think HMAC (in combination with a crypto hash function from the SHA-2 family) is more popular in this situation, since it's hardened against length extension attacks, and it doesn't need all the resources PBKDF2 or even bcrypt need.

Giu 2010-09-18 11:13:41

@Giu: It may be even more suitable for an enterprise intranet site than a public internet site. However, if you consider that the cost/delay is completely configurable and the number of authentications per day is a tiny fraction of the number of page views, I wouldn't rule it out. I do agree that something like HMACSHA256, properly salted, would be a reasonable start. MS .NET has HMACSHA512 built in, if you want to throw bits at it. But I think that more security is to be found in strengthening than just using a wide hash.

Steven Sudit 2010-09-20 01:39:30

@Steven Sudit: Yes, definitely; I wouldn't rule it out, too, in such a situation. If you have that many users and page-views, it's quite probable that additional computing power is available for such a password scheme; at least if you've assembled your server with the right hardware to handle all that traffic with ease. "But I think that more security is to be found in strengthening than just using a wide hash"; I share exactly the same view ;)

Giu 2010-09-20 08:10:18

@Rook Why did you edit the answer? All I can see is that you've changed 2 characters; why? To *unlock* the answer? And why did I get a down-vote? An explanation would be helpful. Thanks

Giu 2010-10-29 06:31:14

@Rook The number of authentications a day that a webapp has to do is a tiny, tiny fraction of the number an attacker has to do, and also a tiny fraction of the total amount of work the webapp does. Increases to the cost of the hash function affect attackers far more than they affect webapps.

Nick Johnson 2010-10-29 07:35:48

@nik johnson @giu the idea of PBKDF2 for web applications is deeply flawed, if you look at its use on wikipeida it is used in areas such as encrypted file systems as a string2key function and only useful with hundreds of thousands iterations and only 1 person logging in a day or so. If its too heavy for the attacker its too heavy for your web server. Many applications require thousands of logins per minute (such as SO). I will not promote the idea of PBKDF2 used in web applications. Try and `openssl speed` sometime.

Rook 2010-10-29 18:56:18

@nik johnson also that link about PBKDF2 bothers me. No serious cryptographer is going to suggest using bcrypt, blowfish was deprecated more than 10 years ago by twofish. No one should use blowfish, not as a block cipher, not as a message digest function.

Rook 2010-10-29 18:57:51

+1 A:

I think Gui's suggestion about PBKDF2 has merit, although I know Rook disagrees strongly. If only they were clear about their reasoning!

Regardless, there's no reason to use a salted SHA-256 hash in comparison to HMAC-SHA256. HMAC has the advantage of blocking extension attacks.

Steven Sudit 2010-09-18 01:51:13

+1 for mentioning HMAC, which I completely forgot to mention as the more secure alternative to a simply salted SHA-256 hash. Length extension attacks are well known; the Flickr API once was compromised because it used to sign API calls using `MD5(secret + argument list)` (see " [Flickr's API Signature Forgery Vulnerability](http://netifera.com/research/flickr_api_signature_forgery.pdf) " [PDF] for further information)

Giu 2010-09-18 10:50:39

ansaurus

tags:

views:

answers:

Do any security experts recommend bcrypt for password storage?

related questions