Why not just iterate a hash function 10,000,000 times? [duplicate]

Question

I've read many posts on SO on how you should implement password hashing. And I've read that you shouldn't hash the password many times (well, it doesn't help much, it is said). But why not? If I iterate the hashed passwords, let's say, 10,000,000 times (because user can wait 3 seconds to have his registration completed, or I could just do that by sending an AJAX request).

So, how an attacker, stolen my database, and even knowing that I just iterate the password 10,000,000 times (worst-case scenario), could possibly find out users' passwords? He couldn't create a rainbow table, as it would take him very long (hashing passwords takes time, and hashing the hash so many times takes much more time), brute-force is also not really possible, so what's left?

Answer 1

evening: I wasn't saying anything about bcrypt or PBKDF.

Your question implicitly screams "I am trying to kludge my way around having to use bcrypt/PBKDF by poorly imitating their methods". However, the problems raised in the duplicate question are the reason why these new algos were devised instead of simply re-hashing a key X times.

You want a simple answer? Then: yes. X+1 hashing rounds are more secure than just X hashing rounds, but only marginally so. You might spend a second or two computing the hash on your server by looping over $hash = hash('sha512', $hash); But an attacker is going to use the Slide Attack to cut that down to a fraction of the time, and on top of that they're likely going to parallelize the attack across a few AWS instances, a farm of graphics cards, or a botnet.

The methods that PBKDF and bcrypt employ go quite a ways towards minimalizing/negating the effect of the slide attack, and bcrypt does some sort of magic voodoo that prevents it from being parallelizable to some extent.