2

As in md5(md5(md5(x)))...

I can remember coming across that in some piece of code. If the attacker can somehow reverse md5(md5(md5(x))) into md5(md5(x)) then he certainly can reverse md5(md5(x)) into md5(x) and the x. However if it takes some good amount of time to reverse the first hash then hashing the hash can slow him down. I cant make up my mind on this issue hence the question

Ulkoma
  • 8,793
  • 16
  • 65
  • 95
  • I assume you mean getting md5(md5(x)) from md5(md5(md5(x))) by means of a brute force attack rather than by "reversing"? – ilikebeets Aug 27 '14 at 19:45
  • I mean "figuring it out" in any possible way.. I still don't know how NSA decrypt hashes, brute force? I don't think so – Ulkoma Aug 27 '14 at 19:47
  • Mathematically it is impossible to reverse a hashing algorithm (derive the original input from the resultant signature). That is why they are called one-way cryptographic hash functions. – ilikebeets Aug 27 '14 at 19:49
  • Yes, I am aware of that, maybe I've used the wrong word, apologies, I just cant stop thinking of NSA and they can decrypt hashes – Ulkoma Aug 27 '14 at 19:51
  • 1
    Hashing functions, by definition, are one way and cannot be reversed. Hashes are indeed attacked by brute force by the NSA and everyone else. – Xander Aug 27 '14 at 19:52
  • 2
    Why do people still talk about MD5 as an example hash function? That algorithm isn't just dead, it is dead, cut into pieces, dissolved in acid, incinerated and buried. – Philipp Aug 27 '14 at 21:22
  • 2
    Would naively iterating the hash like this make collisions way more likely, since the collision can happen on any iteration and be propagated through? – Andrew Aug 27 '14 at 21:33
  • @AndrewPiliser Collision resistance is relatively irrelevant for password hashing. The chance that you'll encounter a collision is so far less likely than the chance that you'll be able to brute-force the password so as to be immaterial. – Xander Aug 27 '14 at 23:28
  • A more direct duplicate question and answer: [Why do people think this is a bad way to hash passwords?](http://security.stackexchange.com/a/5592/12) (I finally found it!) – Xander Aug 28 '14 at 01:03

4 Answers4

3

Assuming the hash is being cracked using brute force techniques, hashing the hash would mean that theoretically you will need more time and resources to crack that hash due to the fact that you need to execute multiple iterations of the algorithm.

However, having said that, if it is time you are looking for MD5 is most certainly not the way to go. In order to make a hash as difficult to crack as possible I'd recommend a "slow algorithm" like PBKDF2.

By doing multiple iterations of PBKDF2 you will make the process of cracking the hash so slow (relative to other algorithms) that it will become virtually impossible to crack the hash in any reasonable amount of time.

Edit: When I say multiple iterations I don't mean 2 or 10, I mean thousands or hundreds of thousands depending on the acceptable amount of time you are willing to wait for a legitimate hash to be generated or compared.

ilikebeets
  • 2,646
  • 15
  • 21
  • 4
    Upvoted, but I'd state it more strongly. Use BCrypt or PBKDF2, with an appropriate work factor. Repeatedly hashing with MD5 is essentially rolling your own crypto, since it's a construction that hasn't been examined and passed muster. It shouldn't be done. – Xander Aug 27 '14 at 20:06
2

This particular implementation is naïve and doesn't help. A stock PC can calculate billions of MD5 hashes per second, so having to calculate some more simply isn't relevant.

The concept of iterated hashing is valid, though. If you look at professional algorithms like bcrypt, they actually do repeat their internal hash procedure in order to make the algorithm more expensive. But that alone isn't enough:

  • The whole algorithm must be carefully designed by experts to make sure that it's cryptographically sound. Home-made schemes are never a good idea.
  • The number of iterations must be variable so that the algorithm can be adapted to new hardware. What might be good enough today certainly won't be good enough in a few years.
  • All modern password hash algorithms have an additional parameter for a random string (“salt”) that is mixed into the input. The problem of your scheme is that the same input always leads to the same hash, so an attacker can reuse the calculated results accross multiple user accounts, they can precalculate the hashes, and they can even recognize identical passwords. Salts prevent this, because they force the attacker to break each hash individually.

Those principles lead to modern hash algorithms like bcrypt, scrypt or PBKDF2.

Fleche
  • 4,024
  • 1
  • 17
  • 20
  • The speed of a single iteration does not matter much. The faster an attacker can calculate hashes, the faster your password server can, allowing you to proportionally increase the number of iterations required. Of course, I agree this particular implementation is naïve and should be avoided for reasons stated. – Marcks Thomas Aug 27 '14 at 21:57
  • 1
    I never said that a single iteration must be slow. In fact, PBKDF2 is commonly based on fast hash algorithms like SHA-1. The point is that repeating MD5 a few times as demonstrated in the question doesn't help. – Fleche Aug 27 '14 at 22:18
0

Yes, it is an extra level of security. For standard md5 (other than the fact that it can be cracked quickly) there are massive lists of already cracked md5 hashes. However, if you reuse the hashing algo a couple of times, it will be harder to crack the hashes. That is called "rounds".

Some algorithms have a default amount of rounds to slow down the cracker. If you have a n round function, it takes the attacker n times longer to crack the hash than normal.

Another way of increasing security would be by implementing a salt in the hashes.

Finally, making sure to use a secure algorithm (Whirlpool for example) will also help improve security.

crypto
  • 104
  • 5
0

MD5's are great, but not for security. Yes, it will, in theory, add some additional level of security, whether or not it is enough depends on your application. You have to look beyond added security. What does it cost to hash the hash as opposed to starting with a far superior algorithm. Despite a theoretical added security, if you need to hash an MD5, you are using the wrong tool for the job.

MD5s are fine for most file comparison applications.

Randy Abrams
  • 11
  • 3