Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote 4 down vote favorite
2

What is nowadays (July 2012) the recommended number of bcrypt rounds for hashing a password for an average website (storing only name, emailaddress and home address, but no creditcard or medical information)?

In other words, what is the current capability of the bcrypt password cracking community? Several bcrypt libraries use 12 rounds (2^12 iterations) as the default setting. Is that the recommended workfactor? Would 6 rounds not be strong enough (which happens to be the limit for client-side bcrypt hashing in Javascript, see also Challenging challenge: client-side password hashing and server-side password verification)?

I have read answer http://security.stackexchange.com/a/3993/11197 which gives an in-depth discussion how to balance the various factors (albeit for PBKDF2-SHA256). However, I am looking for an actual number. A rule of thumb.

share|improve this question
I do 120.000, but it depends on your application. It just depends on your app, and your CPU power you can spend on it. E.g. if you have a 1 user login per second and using 2 cores only, you would not do more than 10.000 I think. Basically you need to check how long it takes with "time" command and see for yourself. Something close to second should be OK. – Andrew Smith Jul 14 '12 at 20:13
@Andrew: The speed of my own system should not be leading for the number of iterations. It is the current speed of the brute-forcers that should dictate how many iterations are considered safe. Hence my question: how many iterations are nowadays considered safe? – Jason Smith Jul 14 '12 at 21:43
@JasonSmith, The speed of your system is relevant, because it determines how many iterations you can reasonably do without bogging down your system. You want as many iterations as possible, because the reality is that no number of iterations is enough to be completely safe: we're just reducing the risk somewhat, not eliminating it. There is no realistic number of rounds that is large enough to be considered safe. If you ask a question here, please be prepared to listen to the answers you get. – D.W. Jul 15 '12 at 22:59
@D.W. wrote "please be prepared to listen to the answers you get", sorry if I gave the impression being pedantic or stubborn. Perhaps as a non-native English speaker my comments conveyed the wrong message. I do appreciate all answers, and try hard to understand the rationale behind them. – Jason Smith Jul 16 '12 at 12:08
@JasonSmith, ok, my fault for misunderstanding, sorry! – D.W. Jul 16 '12 at 17:46

2 Answers

up vote 3 down vote accepted

I think the answer to all of your questions is already contained in Thomas Pornin's answer. You linked to it, so you presumably know about it, but I suggest that you read it again.

The basic principles are: don't choose a number of rounds; instead, choose the amount of time password verification will take on your server, then calculate the number of rounds based upon that. You want verification to take as long as you can stand.

For some examples of concrete numbers, see Thomas Pornin's answer. He suggests a reasonable goal would be for password verification/hashing to take 8 milliseconds per password. That still lets your server verify 125 passwords per second, which seems more than enough. Thomas estimates that, if this is your goal, about 20,000 rounds is in the right ballpark.

However, the optimal number of rounds will change with your processor. Ideally, you would benchmark how long it takes on your processor and choose the number accordingly. This doesn't take that long; so for best results, just whip up the script and work out how many rounds are needed to ensure that password hashing takes about 8 milliseconds on your server (or longer, if you can bear it).

share|improve this answer
1  
Time doesn't matter, money is why the world spins. – Rook Jul 15 '12 at 23:39
I have a hard time understanding the reasoning that my platform determines the amount of hashing rounds. A client-side Javascript bcrypt implementation can do about 2^6 rounds on a legacy mobile device, my most recent hardware can do 2^13 rounds. However, you commented elsewhere that "12 rounds is almost certainly not enough". How can the speed of my implementation be relevent? Perhaps this just means I need to buy faster hardware and can't run a secure website on an old Pentium 4 which does 2^4 rounds? – Jason Smith Jul 16 '12 at 9:00
If 12 rounds is the best you can do, go with that. The summary version is that you want to use as many rounds as you can tolerate (for any reasonable number of rounds, even more will be even better). Therefore, the speed of your implementation is relevant, because it places an upper bound on the number of rounds you can use (if you set the number of rounds ridiculously large, it'll take too long). I recommend setting the number of rounds as close to that upper bound as possible. That's why the speed of your implementation is relevant. – D.W. Jul 16 '12 at 17:47
1  
P.S. I do not recommend implementing bcrypt in Javascript, as performance will likely be very poor. I assume you are computing bcrypt on the server. (I do not think there is sufficient value to computing bcrypt on the client, so I do not recommend computing bcrypt on the client.) I suggest using a native, optimized implementation of bcrypt; that will run much faster. – D.W. Jul 16 '12 at 17:49
up vote 1 down vote

Stronger Key Derivation via Sequential Memory-Hard Functions is a very good paper on the topic of key stretching. On page 14 it compares various hashing algorithms with how much money it will cost to break the hash, which is a useful way of thinking about these things. (On a side note ChromeOS uses Scrypt if TPM isn't available.)

The idea is that you want these password hashes to be unbroken for as long as possible. With Moore's law this is a exponentially fast moving target. Scrypt uses variable amount of memory and cpu, this variable could become heavier as a function of time. In that each time the client logs in you can update the password hash to be more secure. In the case of PBKDF2 this could look like rounds=2^(current_year-2000) or something like that.

Its important to note that you can't just offload this processing onto the client and expect your protocol to be secure. All client-side hashing authentication protocols I know of require the server to make an identical calculation in order to verify the authentication credentials (NTLM, NTLMv2, SRP, WPA-PSK...).

share|improve this answer
I am aware I should match Moore's law. But that is exactly my question: how many iterations are nowadays considered safe given the current speed of the brute-forcers? – Jason Smith Jul 14 '12 at 21:47
1  
@Jason Smith I don't think anyone can give you a real number because it is circumstantial. My answer was 2^12, which is 4096 and my rationale is because its 2012. – Rook Jul 14 '12 at 22:02
Ah, I thought 2^(current_year-2000) was just an arbitrary example. Ok, so 12 rounds in 2012. – Jason Smith Jul 15 '12 at 10:44
No, 12 rounds is almost certainly not enough. – D.W. Jul 15 '12 at 22:59
@D.W. 4096 iterations is larger than most implementations i have seen, keep in mind next year it will be 8192... – Rook Jul 15 '12 at 23:42

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.