5

I'm currently developing a small project in PHP, and as it involves user authentication, I've been researching what options I've got regarding hashing. I've settled on PBKDF2 primarily due to it's iterative nature, flexibility with hash algorithms, and extendibility.

What I've been reading is that 8ms (or 0.008 seconds) is something of a goal for generating a hash. Why is this specific value the goal? I understand the reasoning behind making it take more time to generate a hash, but why 8ms specifically? It it simply a good balanced value between time taken and security, or is there a more specific reason?

Theoretical

Let's say I've got a server that can do 6400 iterations with SHA256 with a key length of 6 characters, with a salt that's X characters long and a password that's Y characters long in just under 9ms. I'm not sure if it's 'the fear' that's been put into me, but I wouldn't consider this sufficient primarily because of the low iteration count and extremely short key length despite it being salted and hashed with what is for all intents and purposes a secure algorithm. What's 9ms on my system will be significantly less on a system dedicated to 'cracking' the hash. Again, these values are just theoretical - don't look into them too much.

So, let's assume I go to 64000 iterations with a key length of 60. This takes almost 90ms to calculate, and I'd consider this secure for all intents and purposes, both due to it's high iteration count, it's output key length and the time it takes to generate.

More to the point, it would take 10x longer to calculate the latter hash (compared to the first) regardless of the system it's being calculated on, despite it taking ~91% longer than the '8ms rule' when run in the original environment.

So, where did this value of 8ms originally come from and on what grounds is it recommended exactly? Is the 8ms based on your environment' calculation time, or is it calculated through some other means (e.g. via a dedicated hash application running on a GPU)?

8ms Recommendation Source #1

8ms Recommendation Source #2

Community
  • 1
Scott P
  • 175
  • 6
  • can you remember where you read that? I can't find this recomendation anywhere... – woliveirajr Jun 05 '13 at 19:47
  • @woliveirajr I've added 2 sources where it's recommended to the question, and I'm fairly sure that there's a few more out there. Will update as I find them. – Scott P Jun 05 '13 at 19:59
  • Those are actually the same source. Thomas Pornin made the 8ms recommendation in the first linked article, then someone referred back to his answer from the second article. Neither gives any justification, and it sounds like a arbitrary number chosen from thin air. [Moores Law](http://en.wikipedia.org/wiki/Moore's_law) guarantees that the 8ms time will be cut in half every 18 months. – Johnny Jun 05 '13 at 21:44
  • @Johnny Moore's law is about the doubling of transistors on a die, not processor speed, and it hasn't held as true for quite some time now anyway. – forest Feb 10 '18 at 22:55

2 Answers2

8

There is no "8 ms rule". There's an equation that was explained by Thomas Pornin (your first link) which stated in that example that for 32 bits of password quality and an attacker with 200 times the computing resources as your hashing system devoted to cracking hashes would complete the task in one month if it took you 8ms to run a hash. You need to adjust those assumptions about password strength, attacker resources, and your devotion of resources to fit your needs.

Community
  • 1
Jeff Ferland
  • 38,090
  • 9
  • 93
  • 171
  • And with things like AWS, the money required for 200x computing resources * 1 month is a more useful calculation. Because if it is "embarrassing parallel" and you can use utility computing, it all comes down to how much money you want to spend on cracking it. – Bradley Kreider Jun 06 '13 at 00:55
  • Note that, particularly with PBKDF2-HMAC-MD5/SHA-1/SHA-224/SHA-256, a single attacker computer loaded with 2014 vintage GPU's can run PBKDF2 tries roughly 1000 times as fast as about 8 cores worth of your CPU... and 8000 times as fast as any one of your cores (and any one try is single threaded due to the design of PBKDF2). Moving to PBKDF2-HMAC-SHA-384 or PBKDF2-HMAC-SHA-512 reduces the magnitude of the attacker's advantage at time time, since current GPU's do the 64-bit operations more poorly than 64-bit PC's with 64-bit OS's and 64-bit code to - a proportionate win for the defender (you). – Anti-weakpasswords Mar 12 '14 at 04:52
2

Ok, based on the link /source you provided: there is no correct, specific value of the PKBDF2 number of iterations.

What Thomas Pornin states in his answer is that you can do some rough calculations to estimate a good balance between how much computer power you'll use in your system, to authenticate users, and how much an attacker would be willing to spend trying to break it.

All numbers he used in his answer are guesses: he is assuming that anyone attacking you will have 100 computers, and that each computer will have the double computing power than yours. So, to take a month trying to break your system, his calculation gives that 8 ms in your system, per hashing generation, will mean that the attacker would spend a whole month in a brute-force attack.

The other source you mention is also a reference to this first answer.

It that a goal? Perhaps, if you are in the scenario he describes.

Why bother with the 8 ms? Because it is a number to start with, since that answer is very explanatory on how the 8 ms was reached.

If you're expecting to have fewer than 125 logins per second, you can increase the number of iterations of the PKBDF2, and be more secure...

woliveirajr
  • 4,462
  • 2
  • 17
  • 26