64

It's still a commonly recommended way of hashing passwords, even if its insecurity had been proven in 1996:

Therefore we suggest that in the future MD5 should no longer be implemented in applications like signature schemes, where a collision-resistant hash function is required. According to our present knowledge, the best recommendations for alternatives to MD5 are SHA-1 and RIPEMD-160.

(The Status of MD5 After a Recent Attack, CryptoBytes, RSA Laboratories, VOLUME 2, NUMBER 2 — SUMMER 1996)

Even after this study, and all upcoming papers about its defects, it has been recommended as a password hashing function in web applications, ever since.

It is even used in some Certification Authorities digital signature (according to rhmrisk link below )

What is the reason why this message digest algorithm has not been prohibited for security purposes?

Links:

Marek Sebera
  • 2,223
  • 3
  • 21
  • 27
  • 5
    This question feels awfully close to being a rant, from my perspective. Can you re-phrase it into a factual question? Please make sure to document all your premises/assumptions. – D.W. Jun 07 '12 at 18:11
  • 1
    In the 9 years since you posted those links, most of them have aged out or they no longer apply (they do not mention using MD5). – schroeder Apr 06 '21 at 08:38
  • @schroeder sorry, overlooked, thank you for removing links that no longer work – Marek Sebera Apr 06 '21 at 10:48

8 Answers8

87

To complement the good answer from @D.W.: for password hashing, MD5 is no more broken than any other hash function (but don't use it nonetheless).

The full picture: MD5 is a cryptographic hash function which, as such, is expected to fulfill three characteristics:

  • Resistance to preimages: given x, it is infeasible to find m such that MD5(m) = x.
  • Resistance to second-preimages: given m, it is infeasible to find m' distinct from m and such that MD5(m) = MD5(m').
  • Resistance to collisions: it is infeasible to find m and m', distinct from each other, and such that MD5(m) = MD5(m').

MD5 is thoroughly broken with regards to collisions, but not for preimages or second-preimages. Moreover, the 1996 attack (by Dobbertin) did not break MD5 at all; it was a "collision on the compression function", i.e. an attack on one of the internal elements of MD5, but not the full function. Cryptographers took it as a warning flag, and they were right because the actual collision attack which was published in 2004 (by Wang) was built from the findings of Dobbertin. But MD5 was broken only in 2004, not 1996, and it was a collision attack.

Collisions are not relevant to password hashing security. Most usages of a hash function for password hashing depend on either preimage resistance, or on other properties (e.g. how well the hash function work when used within HMAC, something which cannot be reduced to any of the properties above). MD5 has actually been "weakened" with regards to preimages, but only in a theoretical way, because the attack cost is still billions of billions of times too expensive to be really tried (so MD5 is not "really" broken with regards to preimages, not in a practical way).

But don't use MD5 anyway. Not because of any cryptographic weakness, but because MD5 is unsalted and very fast. That's exactly what you do not want in a password hashing function. People who "recommend MD5" for password hashing just don't know any better, and they are a testament to a Truth which you should always keep in mind: not everything you find on the Internet is correct and trustworthy. Better solutions for password hashing are known, and have been used and deployed for more than a decade now. See this answer for details and pointers.

Community
  • 1
Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
  • 1
    Using MD5 by itself for hashing passwords is not a good idea, because it requires users to chose very strong passwords in order to be secure. However a standard construction for computing a salted password hash using MD5 does exist, and to the best of my knowledge, that is not broken yet. – kasperd May 10 '15 at 08:57
  • 7
    Your correct statement about MD5 being too fast and unsalted aside (because that also goes for the SHA family) I would _still_ stay away from MD5 for a non-technical reason: Public Relations. It's a drag to have to convince your boss or client of what you explain. And tons of technical guys (whose opinions are valued by the same people you are trying to convince) are also deluded. After all, there is plenty of 'proof' on the internet that support their conviction that MD5 should not be used _because_ it was broken in 2004. – mgr326639 Dec 17 '15 at 17:40
  • 3
    Regarding the resistance to preimages,I wonder why you didn't mention *[Yu Sasaki; Kazumaro Aoki (16 April 2009). "Finding Preimages in Full MD5 Faster Than Exhaustive Search". Springer Berlin Heidelberg](http://www.springerlink.com/content/d7pm142n58853467/)* **and/or** [*Ming Mao and Shaohui Chen and Jin Xu (2009). "Construction of the Initial Structure for Preimage Attack of MD5". International Conference on Computational Intelligence and Security. IEEE Computer Society](http://ieeexplore.ieee.org/document/5376483/)* which point to a (theoretical) break of MD5's preimage resistance in 2009. – e-sushi Jul 26 '17 at 14:10
  • @e-sushi Well, that's what I meant by "weakened in a theoretical way". – Thomas Pornin Jul 26 '17 at 17:17
  • @ThomasPornin In that case, simply ignore my comment and think of it as a confirming addition to underline your statements. ;) – e-sushi Jul 26 '17 at 20:30
  • If MD5 is fast enough that it can be brute forced, then the resistance to pre-image attacks is broken. Nothing about the property says the attacker can't use brute force as the attack method. – jpmc26 Sep 22 '21 at 17:28
32

What do you mean "prohibited"? Who would "prohibit" use of MD5? It's not like we have some International Crypto Cops who go arrest people who use ROT13 and other insecure crypto schemes.

Or, to be a bit more serious: cryptographers already recommend that new systems should avoid MD5, and they recommend that existing systems should migrate away from MD5. I don't know what more you think cryptographers can do about this.

You claim that MD5 is a "commonly recommended way of hashing passwords", but you provide no evidence for this claim. I don't think the claim is correct. That's not been my experience.

The bottom line is that the cryptographic community is already speaking pretty clearly, with one voice, on this topic, and most folks are already migrating away from MD5. The cases where MD5 is still used are the exception, not the norm.

Edit (6/17): I see that you added some links that mention use of MD5 for hashing. All that they prove is that some people I've never heard of are confused. So what? You probably should be skeptical taking advice from people who have not established a positive reputation in the security/cryptography community, anyway. And I don't understand how you can criticize the security/cryptography community over the fact that some people who are not in the community are confused. What, exactly, are we supposed to do? We already do everything we can to expand knowledge about the right way to do it. I feel that you are really placing the blame on the wrong folks.

Anyway, to answer your question about why some folks still recommend MD5: well, gee, it's probably because those folks don't know any better. I don't know what more anyone can say about the subject, or what more you expect anyone to say.

D.W.
  • 98,860
  • 33
  • 271
  • 588
  • the word "prohibit" is probably used in bad way. I mean more like put a big warning screens around it, and point the developers to SHA or Blowfish, as it can serve the same purpose. And yes, it's getting used to be less used, but we can still find many articles on MD5, where used in password hashing is not rejected. I've added some links to bottom of question, that refers to MD5 as secure hashing algorithm, to prove my claim. – Marek Sebera Jun 17 '12 at 19:28
  • 4
    @MarekSebera In the context of password hashing there is no known attack on md5 that doesn't apply to Sha1/2. And blowfish is not even a hashfunction. – CodesInChaos Jun 17 '12 at 21:29
  • My wrong with Blowfish, but in terms of "Collision attack", the SHA2 is still safe, and SHA1 is attacked only theoretically, so far there is no fast collision search algorithm, that would breach the security of SHA1/2. If you're talking about SHA rainbow tables or bruteforce attack, yep, these functions are not secured (but which hashing function is) against them – Marek Sebera Jun 17 '12 at 22:26
  • 3
    @MarekSebera My point is that collisions attacks are completely irrelevant in the context of password hashing. Even a hashfunction that allows the construction of collisions with pen&paper may be completely secure for password hashing, as long as first pre-images are still hard to find. – CodesInChaos Jun 18 '12 at 08:51
  • @CodesInChaos Why collisions are irrelevant with password hashing? A password hashing scheme whereby two passwords are hashed two the same digest don't violate the security of the password hashing scheme? That means another user with different password is authorized to access – curious Feb 22 '13 at 09:29
  • 3
    @curious With a collision vulnerability the attacker needs to control both strings. Who cares if the attacker can create an account for which he knows two different passwords, it's his account anyways. Proper use of salting (HMAC or prepend to password) blocks normal collision attacks, so you won't even be able to find collisions against PBKDF2-HMAC-MD5. – CodesInChaos Feb 22 '13 at 09:38
  • So why the password hashing competition? Since password hashing schemes work fine? – curious Feb 22 '13 at 09:44
  • 2
    I imagine the reason he says MD5 is "commonly recommended" is because there are so many really old tutorials kicking around on the web that haven't been updated in a decade or more. The trouble is that because they've been around for so long, they often show up relatively high in the searches, so they get a lot more traffic than they deserve. StackOverflow is constantly getting naive questions from people referring to ancient tutorials. – Spudley Mar 03 '13 at 19:02
  • *"It's not like we have some International Crypto Cops who go arrest people who use ROT13"* Actually, yes we do. You're expected to take reasonable measures to protect people's data according to privacy laws, at least in the Netherlands... – Luc Mar 01 '18 at 11:30
10

I think what you're seeing is the web's long tail. I can find articles from 2006 recommending MD5 for password hashing (e.g. http://www.pixel2life.com/publish/tutorials/118/understanding_md5_password_encryption/) - still 10 years after your reference date.

However we're talking about the time for something to get from cutting-edge research in the peer reviewed cryptography journals to recommend practice among everyday practitioners who don't read cryptography journals and aren't even experts in that field. What probably happened is that because in 1990 everyone "knew" that MD5 was good for passwords, they told everyone else that MD5 was good for passwords. From the late-1990s some people were saying that MD5 was bad for passwords, but most people "knew" it was good for passwords and this was still what they advised others.

These days, there's a large enough body of people who "know" that bcrypt is good for passwords that you're starting to see those recommendations, but the articles saying that MD5 is good for passwords have not yet decayed out of the search engine indices. Over time, they will.

Which means that in a decade's time you'll come back here and ask the question "why are people still recommending using a bcrypt work factor of 10 when this journal says you should use at least 150?"...

Poul Henning-Kamp originally moved the UNIX crypt() function from DES to MD5. He explains here that the fact people are using MD5 demonstrates that he didn't successfully describe what he was trying to do: make password hashing more complex, not install MD5 as a shibboleth.

Marek Sebera
  • 2,223
  • 3
  • 21
  • 27
  • I agree, long tail of changing minds of many developers, that relied on MD5 for a long time. And thanks for mentioning the `bcrypt`, as it is fine hw-scalable algorithm, and I'd recommend it too. Maybe it would be nice, to see Google blacklisting articles recommending MD5 for such purposes :D – Marek Sebera Jun 17 '12 at 19:35
  • 1
    @MarekSebera I'm not sure I want to see search engines censoring any content. –  Jun 18 '12 at 08:52
  • yup, that was not serious idea, even if I'd bet, that this is not already done. – Marek Sebera Jun 18 '12 at 09:26
6

You have several usages of MD5

Integrity checking

Checking that the file you have downloaded or received is the original by checking the hash of the file. It has been shown that you can easily create a file that has the same checksum.

Collision in MD5 is easy to produce. MD5 should not be used for that purpose.

People still propose MD5 checksum while downloading iso and stuff but often also gives SHA checksum. This can be explained because MD5 is a lot faster and usually implemented.

Password checking

Instead of storing a password in clear text, you store the hash of the password. Some websites still use MD5 to do that. The problem here is not to find a collision but to check a rainbow table or a huge database of MD5 checksum.

As you can produce very quickly millions of MD5 checksums, you can brute force a password on your own PC. You should not use MD5 for hashing your password for that reason but mostly, you should add a salt.

If you have a very complex password (long with special characters) and a unique complex salt for each stored password, it is not that much a problem for you to use MD5. I don't say you should (you shouldn't) but it is not a huge security issue to use MD5 if the password will be hard to brute force and the use of rainbow table is prevented by the salt. Of course, on your website, it is not easy (and appreciated) to force the users to have a complex password, so if a user register 12345, no matter what hash function you use, it will be broken.

The reason people still use that is maybe because of it is still the most known hash function and was still acceptable a some years ago. People with not much crypto knowledge may use it.

Martin Trigaux
  • 312
  • 2
  • 9
  • "_If you have a very complex password (long with special characters)_" then it doesn't matter if you have "_a unique complex salt for each stored password,_" – curiousguy Jun 08 '12 at 11:34
  • MD5 should not be used for password checking unless its paired with a secure algorithm. A major problem with MD5 is the small length of the output. – Ramhound Jun 08 '12 at 15:57
  • @Ramhound Please define "secure algorithm". "_A major problem with MD5 is the small length of the output._" Hug? – curiousguy Jun 09 '12 at 07:10
  • @curiousguy yes, the salt matters because it prevents creating a rainbow table that can be used for any password. Here you would need to build one table per password (and salt). – Martin Trigaux Jun 09 '12 at 12:27
  • @Ramhound the problem with the small length output could be the risk of collision but for a password it is anyway very weak, even with "only" 128bit – Martin Trigaux Jun 09 '12 at 12:27
  • @MartinTrigaux The salt matters when your password is not trivial but not as strong as possible. An extremely strong password needs no salt. – curiousguy Jun 10 '12 at 12:25
  • 3
    I don't know why this answer has been downvoted so much. It has good, useful information. The points about the distinctions between integrity checking and password checking are perfectly valid; the two applications have different security requirements. P.S. One room for improvement in the answer is that it's not enough to recommend use of a salt; you should also recommend use of a slow hashing function, like scrypt, bcrypt, or PBKDF2. – D.W. Jun 14 '12 at 18:14
3

I don't think that it is recommended. Wikipedia states that MD5 is considered broken and SHA-2 or SHA family is recommended to replace it. Also take a look at Devise, a ruby gem that handles authorization. It has a different type of encryptor.

Travis Pessetto
  • 670
  • 3
  • 6
  • 1
    And I think, with the suggestion of a ruby gem, therein lies the rub. "People" who are implementing MD5 are doing so not because they are willfully trying to use a broken hash function, but because they are using gems, modules, software, etc. that has not been updated to use more secure methods. They don't know any better, and, apparently they don't care. – logicalscope Jun 07 '12 at 19:21
  • 2
    Well if it help php.net itself recommends not using it for passwords "It is not recommended to use this function to secure passwords, due to the fast nature of this hashing algorithm. "-http://php.net/manual/en/function.md5.php – Travis Pessetto Jun 07 '12 at 19:31
  • Also, there is no requirement for storing information unless you are doing something like credit-card processing requiring your web application to be PCI compliant. – Travis Pessetto Jun 07 '12 at 19:35
  • How is MD5 "broken" for the purpose of hiding passwords? – curiousguy Jun 13 '12 at 13:39
  • 1
    @curiousguy MD5 is broken because it can be cracked easily via brute-force. Pretty much if you get a hold of the hash you can figure out what the password was in a short time. Not sure exactly how long, but I believe it is only a couple minutes top. This is done by just trying everything until the hashes are the same, and since the MD5 algorithm is fast it is easy to do that fast. – Travis Pessetto Jun 13 '12 at 14:03
  • @TravisPessetto "_MD5 is broken because it can be cracked easily via brute-force._" when a weak password is used. "_Not sure exactly how long, but I believe it is only a couple minutes top._" because you used a weak password "_This is done by just trying everything until the hashes are the same, and since the MD5 algorithm is fast it is easy to do that fast._" which is only possible **if you can enumerate every password, because your password is weak** – curiousguy Jun 13 '12 at 17:00
  • 1
    @curiousguy Taken from [PHP.net](http://www.php.net/manual/en/faq.passwords.php#faq.passwords.fasthash) "Hashing algorithms such as MD5, SHA1 and SHA256 are designed to be very fast and efficient. With modern techniques and computer equipment, it has become trivial to "brute force" the output of these algorithms, in order to determine the original input. Because of how quickly a modern computer can "reverse" these hashing algorithms, many security professionals strongly suggest against their use for password hashing. " – Travis Pessetto Jun 13 '12 at 17:13
  • 1
    @TravisPessetto This is utter bullshit from PHP.net. None of these function is invertible with existing technology. This guys obviously have no understanding about what they are talking about and **should never be trusted**. (BTW, PHP is such an ugly language that it is hardly a surprise that theses guys are incompetent morons.) – curiousguy Jun 13 '12 at 17:52
  • 2
    @curiousguy, I don't think it's bullshit. It is perfectly standard advice. Standard advice is to use a slow hash, like bcrypt, scrypt, or PBKDF2, not a fast hash like MD5, SHA1, or SHA256, if you need to hash passwords. (When they refer to "brute force", they probably mean dictionary attacks, that enumerate common passwords. Those attacks are very effective, as many people choose passwords with not-very-high entropy.) Search for "passwords" on this site to learn more. – D.W. Jun 14 '12 at 18:12
2

Even after this study, and all upcoming papers about it's defects, it has been recommended as password hashing function in web applications, ever since.

Yes, and?

Password hashing is just time wasting.

MD5^n (MD5 iterated n times) is just as good as SHA1^m (for m such as time(MD5^n) >= time(SHA1^m)) for time wasting.

Nobody has suggested any way to compute MD5^n in way that is faster than the obvious MD5 o MD5^(n-1). There is not even the beginning of an idea to do that.

Nothing is broken here.

For time.space wasting, you should consider scrypt.

curiousguy
  • 5,038
  • 3
  • 25
  • 27
  • 2
    "MD5^n (MD5 iterated n times) is just as good as SHA1^m" - **THIS iS 100000000% false** You can perform MD5 infinity times on a string and the output is known. MD5 is not secure and SHOULD NOT BE USED to hash passwords by itself. SHA256 is secure MD5 is NOT. – Ramhound Jun 08 '12 at 15:59
  • @Ramhound I agree, if the hashing function is not secure at first iteration, it won't be more secure on multiple iterations. But on the other hand, if you proceed the hashing 10 times, it means, for attacker, generating tables will be approx. 10 times slower, which is little satisfaction – Marek Sebera Jun 13 '12 at 12:40
  • @MarekSebera "_I agree_" you agree with what? "_if the hashing function is not secure at first iteration_" what do you mean by "secure"? – curiousguy Jun 13 '12 at 13:41
  • @Ramhound "_THIS iS 100000000% false_" Do you think that an algorithm which is slower than another one is not slower? – curiousguy Jun 13 '12 at 13:42
  • I agree that if first iteration of MD5 doesn't hash the password in such way, to make it secure (means no possibility of crack, until you realize out what the plaintext is, no matter if dictionary, bruteforce, or whatever), then running it N-times cannot raise it's secureness. – Marek Sebera Jun 13 '12 at 14:59
  • @MarekSebera "_if first iteration of MD5 doesn't hash the password in such way, to make it secure_" Well, MD5 **does** hash in a secure way. – curiousguy Jun 13 '12 at 16:14
  • @curiousguy and that is where you are wrong. if MD5 would hash password in secure way, it wouldn't have had collisions and would be recommended. – Marek Sebera Jun 13 '12 at 18:29
  • @MarekSebera This is where **you** are wrong. MD5 has no collision with passwords, and is recommended. – curiousguy Jun 13 '12 at 19:56
  • 4
    @Ramhound, 100000000% false - does that wrap around mod 100, so that it is 0% false? More seriously, you are wrong, and curiousguy is right. Your statements are unhelpful and appear to reflect a misunderstanding of the situation. "X is secure" is not a helpful statement; you have to specify, "secure for what?". If you do that, you'll discover that curiousguy's answer is perfectly accurate. The known collision attacks on MD5 are, well, collision attacks, and they do not endanger use of MD5 for hashing passwords. – D.W. Jun 14 '12 at 18:16
  • 4
    I find it disappointing to see that multiple people have downvoted this answer. Sounds like there is widespread misunderstanding or confusion about the security requirements for a password hash function. In fact, curiousguy's answer is completely accurate. The comments here from @MarekSebera and Ramhound are inaccurate and a bit confused about the security requirements for password hashing. – D.W. Jun 14 '12 at 18:20
  • 4
    I wouldn't use the words "just as good" because I think cryptoanalysis achieving pre-image attacks against md5 is more likely to arrive than against SHA-1. But it's correct in so far, that current attacks on offer no way to find first pre-images for MD5 that are faster than simply guessing the password. – CodesInChaos Jun 17 '12 at 21:38
  • 1
    @CodeInChaos "_I think cryptoanalysis achieving pre-image attacks against md5 is more likely to arrive than against SHA-1_" Yes indeed, but I consider it extremely unlikely that such attack ever become cheap, or cheaper than running the whole dictionary (+ trivial variants like caps or added digit) through MD5. OTOH, such attacks may make it easier to guess a high entropy key K, where MD5(K) is known than by brute forcing the key-space. – curiousguy Jun 17 '12 at 22:41
1

This is an official information about MD5 - MD5 vulnerable to collision attacks For higher security SHA-2 should be considered. No one stops users from using MD5, but not for the data you want to keep private.

Performance of hash algorithms

As shown in the diagram "Performance of hash algorithms", SHA256 is way faster then MD5.

This is a good resource to consider, author looks into LinkedIn leaked passwords- queue(.)acm (.) org/detail.cfm?id=2254400&ref=fullrss, also shows some ways on how to secure passwords.

user1652382
  • 11
  • 2
0

The issue of password hashing and use of rainbow tables is down to the security of a web server being exploited through an underlying weakness.

First up are all these web sites purporting to offer a simple test to see if your password is secure... Ummm well lets look at these sites as phishing and all people rolling up to these sites are doing is feeding a rainbow table. That is one part of the problem.

Second up are people who use web hosting services where the object is to rake in money and forget about web server security, these hosts should be put up against the wall and shot IMHO, part of the security of a users login comes from the security of a web server and the underlying technologies being up to date to stop known exploits from being used.

Third up is that once people get in to their thick heads that while MD5 is not collision resistant or I prefer as robust as it could be, it is still difficult for a users account to be hacked unless you have a web host running an exploitable system, your web coding is not robust and you expose yourself by using a site claiming to check your password security.

For the large part MD5 + a Salt value is adequate security for a user login on a web forum as long as the previously mentioned system and software is not exploitable. Once you have a system that has been exploited for a weakness, running a query for known hash values which don't use a salting system will expose a fourth weakness... the end user.

Fourth up is the end user, your web security is ultimately only as strong as the weakest link and for many they will see the end user as just that and admins need to remember that they are end users of a system and are equally as vulnerable to compromising a systems security by employing sloppy programming or software that is easily broken, poor password security and also failing to change that ADMIN login or using software that today still insists on having the admin login name as Admin and also employing super user accounts.

So it goes without saying, so I will say it anyway, MD5 is not cracked, it is reverse engineered through weak users, weak software and peoples inability to understand a technology. If MD5 is cracked, so is SHA and AES and so on...

Mark Giblin
  • 1