Assuming that I'm doing password hashing properly and using bcrypt, scrypt or PBKDF2, how should I go about choosing an appropriate difficulty factor? i.e rounds for bcrypt, iterations for PBKDF2 and maxtime, maxmem or maxmemfrac for scrypt.
Also assume that the worst-case scenario will happen and my user's hashes and salt (and any application-salt or pepper. You know... worst-case.) will be leaked, either accidentally or deliberately.
I need to choose a value that is:
- Easy enough for me.
- Too hard for an attacker.
The first part is relatively easy. If I choose enough rounds to cause bcrypt to take 0.5 seconds, I can be sure that my users won't see a significant slowdown when they login. (In a web app anyway, 0.5 seconds is not very a long time.) I also know by testing a loop over that function that I can handle many more logins per minute than I am currently seeing. If the rate of logins I get increases, I can lower the number of rounds and migrate users over as each one logs in or I can wait for better, cheaper hardware. When I naturally get better, cheaper hardware in my upgrade cycle I can increase the rounds to compensate.
The question that's more difficult to answer is how hard is too hard for an attacker. Of course it depends on the value of the passwords to a particular attacker but for this question, assume no special value beyond the fact that most of these user/password combinations will work on other sites that actually have value.
If I change the number of bcrypt rounds so that it now takes 0.01 seconds instead of 0.5, has this changed the equation for the attacker so that the brute-forced password is now worth more than the cost to brute-force it? How can I know whether it has or not?
It seems this is fairly easy to calculate based on knowing the following:
- How much a generic username/password pair is worth.
- How much it costs to brute-force a hash of $hash_function with $difficulty_factor.
Since scrypt was designed to be memory-hard rather than CPU-hard, the answer to 2. will vary differently depending on algorithm. It's not a linear speedup as CPU/GPU speeds increase or RAM prices decrease.
Is there a place where can I find out the above information that is updated as new hardware becomes available?
The best resource I have found so far for the value of a password is blog posts by Brian Krebs such as this one and this one. For hashes cracked per second, it's the "Crack me if you can" contest at DEFCON. Hashes cracked per dollar would be nice.
Please ignore in your answers any algorithmic flaws in these algorithms. If one of those is found I would simply switch to one of the other alternative algorithms. I assume that if a flaw is found in any of these it will be all over the security news.
Just found over on Crypto.SE this table from the paper defining scrypt:
All I need is for that table to be updated every year.