58

It's still 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 signa- ture schemes, where a collision-resistant hash func- tion is required. According to our present knowl- edge, 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 it's defects, it has been recommended as password hashing function in web applications, ever since.

It is even used in some Certification Authorities digital signature (according to http://rmhrisk.wpengine.com/?p=60 )

What is the reason, why this message digest algorithm is not prohibited yet in meaning of security purposes?

Links, took me few minutes to find those

| improve this question | |
  • 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 7 '12 at 18:11
  • @Ramhound If you google eg. starter guide to securing PHP web application, 80-95% will use MD5 without giving out notice that this way is insecure. – Marek Sebera Jun 7 '12 at 19:05
  • 1
    @MarekSebera - I don't use random sources in order to learn how to write good secure code. I use sources I known to use good programming concepts. I did a search for starter guide to securing PHP web applications the first article didn't suggest MD5. – Ramhound Jun 7 '12 at 19:16
  • 5
    @Ramhound The cited text says nothing about passwords. There is no known vulnerability in MD5 that would prevent it from being used for password hashing. – curiousguy Jun 9 '12 at 7:18
78

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.

| improve this answer | |
28

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.

| improve this answer | |
  • 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
  • 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 8:51
  • 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 9:38
  • 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 3 '13 at 19:02
8

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.

| improve this answer | |
  • 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. – user185 Jun 18 '12 at 8:52
  • yup, that was not serious idea, even if I'd bet, that this is not already done. – Marek Sebera Jun 18 '12 at 9: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.

| improve this answer | |
  • "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 8 '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 8 '12 at 15:57
  • @Ramhound Please define "secure algorithm". "A major problem with MD5 is the small length of the output." Hug? – curiousguy Jun 9 '12 at 7: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 9 '12 at 12:27
  • 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.

| improve this answer | |
  • 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 7 '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. "-php.net/manual/en/function.md5.php – Travis Pessetto Jun 7 '12 at 19:31
  • 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
  • 1
    @curiousguy Taken from PHP.net "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
  • 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.

| improve this answer | |
  • 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 8 '12 at 15:59
  • 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.

| improve this answer | |
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...

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.