3

I copy-pasted a function that implements the PBKDF2 hashing algorithm in PHP. The function asks for the amount of time that I would want it to loop in order to produce a hash.

Now, I'm wondering, what would be a reasonably high iteration count that ensures a very secure hash, while at the same time does not cause the server to slow down to a crawl.

Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
Sal Rahman
  • 631
  • 1
  • 5
  • 14

2 Answers2

6

Well, you said it. The right count is exactly the count which "does not cause the server to slow down to a crawl". You want it to be as high as can be tolerated, given the hardware you use yourself and the expected average load. As @Jeff said, this is a matter of a benchmark.

The whole concept is about making the password hashing process slow for the attacker. This makes it slow for _everybody, including you, so you cannot make it as you would wish. The principle at work here is that your notion of cost, and that of the attacker, are not exactly proportional: a 1000x cost increase is "free" for you if it means that you will spend 1ms instead of 1µs to authenticate a user, whereas turning a 1-hour attack into a 6-week attack is certainly not free for the attacker.

Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
  • 2
    It also completely depends on what kind of target you are and how determined an attacker is going to be. Nobody's likely to bother with a 6-week attack to hack into a run-of-the-mill web app. But if the password provides access to corporate secrets or accounts worth $10M, then maybe it's worth 6 weeks worth of work... (not that you'd want to protect $10M worth of info with *just* a password). – bstpierre Oct 14 '11 at 16:22
  • 1
    @bstpierre although, astonishingly, many companies seem to do just that... – Rory Alsop Oct 14 '11 at 18:37
3

So Wikipedia's wisdom is that 1,000 iterations was the expected number in the year 2,000. Moore's law says power doubles every 18 months. That makes for (aww, we can't use MathJAX here) 2^(11/1.5), or roughly a factor of 160. By that theory, you should use something in the ballpark of 160,000 iterations.

... but really, just benchmark it. Figure out how many logins per second you want your server to handle and set your number of iterations accordingly. Remember that you can increase the number of iterations over time more easily than you can reduce them (reduction only on login), so shoot a little bit conservatively.

Jeff Ferland
  • 38,170
  • 9
  • 94
  • 172