7

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?

halfer
  • 19,824
  • 17
  • 99
  • 186
good_evening
  • 21,085
  • 65
  • 193
  • 298
  • 3
    Because the fact that hashing returns a simple alphanumeric string is cutting down the attach vectors when it's rehashed – Mark Baker Sep 24 '13 at 21:17
  • You'll just get a lot of redundant data. Use bcrypt or password_hash (php 5.5). – Dave Chen Sep 24 '13 at 21:21
  • @Dagon: I don't think the questions are the same... – good_evening Sep 24 '13 at 21:22
  • i think the *answers* are –  Sep 24 '13 at 21:22
  • @MrJack: So, that's even better, isn't it? Now an attacker have multiple passwords which could be used by the user. – good_evening Sep 24 '13 at 21:23
  • @evening - it takes longer to crack; but with cheaply available cloud computing, that isn't an issue... but after the first hash, the result is a simple alphanumeric string of fixed length, therefore lower entropy than the original password. That gives me options for reducing my attacks if I were a black hat – Mark Baker Sep 24 '13 at 21:23
  • Here, look at https://defuse.ca/php-pbkdf2.htm – Jack M. Sep 24 '13 at 21:29
  • @evening you may not *think* that the questions are the same, but they are. bcrypt and PBKDF do much more than simply re-hashing the input a squillion times. – Sammitch Sep 24 '13 at 21:42
  • @Sammitch I wasn't saying anything about bcrypt or PBKDF. – good_evening Sep 24 '13 at 21:43
  • @MarkBaker: And actually what's the difference between md5 and sha256 or any other hashing algorithm? How can you determine which hashing algorithm is better? By the time it takes to hash? The longer - the better? – good_evening Sep 24 '13 at 21:52
  • @evening - by the probability of a collision would be one way - http://en.wikipedia.org/wiki/Cryptographic_hash_function ... best practise is using a good high-entropy algorithm, salting and with a unique salt each time, and introducing an artificial (and variable) delay in the code – Mark Baker Sep 24 '13 at 21:54
  • In fact, my recommendation is to use the new [password hashing functions](http://php.net/password) if you're on PHP 5.5, or [password_compat](https://github.com/ircmaxell/password_compat) if you're on earlier – Mark Baker Sep 24 '13 at 22:01

4 Answers4

7

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.

Sammitch
  • 30,782
  • 7
  • 50
  • 77
2

Because of exist slide attack, which independent of number of cypher/hash rounds. See: http://en.wikipedia.org/wiki/Slide_attack

olegarch
  • 3,670
  • 1
  • 20
  • 19
  • The slide attack is an attack on block ciphers with weak key schedules to recover secret keys. It is of no relevance to password hashing. – Clement Cherlin May 09 '19 at 12:48
0

Because of MD5's way of encoding it always outputs a string with the same length (32 characters for instance). In essence this means that a string with "I am a string" potentially can have the same hash as the "Whooptydoo" string, although this is a very (to the power of 100) small chance, it is still a chance.

This also means that repeat calculating the hash on your string a X number of times doesn't change the probability of it being cracked, as it doesn't encode it more deeply then it already was.

I hope I explained it clear enough, please comment if I have missed something.

Joseph Callaars
  • 1,770
  • 1
  • 19
  • 28
0

I'm assuming you are talking about hashing the password, and then hashing the hash, hashing THAT hash, etc. You could easily then create a rainbow table that just maps hash values to the hash-of-hash values.

So, if HASH(PASSWORD) = H, and then HASH(H) = H1, HASH(H1) = H2, and so forth, then an easily downloadable rainbow table could contain a list like PASSWORD | H and reverse lookup the password that way. Now just, in addition, have a file that looks like H | H10000 and reverse that as well.

So, you've inconvenienced a would be hacker, maybe. But it's not really "more secure" because it's just a longer road, not really a more treacherous or difficult one.

user2812885
  • 1