Nowadays no one dares to defend md5 for any use, and of course they should not!

However, much popular software still uses md5 in applications such as password hashing (although it's not simple/plain md5 and probably uses advanced techniques such as salt + key stretching). I have heard, for example, that the Drupal CMS uses md5, and as far as I know many other programs still use md5. (I think Apache does, and perhaps quite a lot of forum software perhaps.)

Why is this? Is it tolerable?

It seems these are professional and popular programs with many years of development and informed developers.

  • Iterated+salted MD5 is only slightly weaker than PBKDF2-HMAC-SHA2 for password hashing. So there is no compelling technical reason to switch. With PHP software it might have to do compatibility with older versions of php, which don't offer stronger hashes. Commented Mar 23, 2013 at 20:06
  • 3
    @Wyck What has unsalted MD5 got to do with a password reset functionality? That can be easily accomplished regardless of hashing algorithm.
    – user10211
    Commented Mar 24, 2013 at 8:09

6 Answers 6


Most remaining usages of MD5 are due to developers who just don't know better. If you are a frequent reader of this site, then you will soon learn that the "default" hash function to use is SHA-256; that's what cryptographers and standardization bodies recommend. But you will also notice an apparently endless stream of people who want to use MD5, or suggest MD5, or begin to ask themselves questions about MD5 and are in search of some guidance. This means that:

  • There is a considerably heavy Tradition of using MD5.
  • Information about how SHA-256 is much better than MD5, is not that widespread.
  • Most developers do development and are not skilled about security (and rarely care much about it). The "normal" development method (by which I mean the way most developers work) is:

    1. Google up the current problem.
    2. Copy&paste the first decent-looking solution that appears in some random blog or Q&A site.
    3. Compile, run.
    4. If it seems to work, blog about it. (optional)
    5. Go to the next problem.

    It is no mystery that 95% (at least) of Web sites and related applications are developed that way. But the Web is full of MD5; therefore, most applications will be full of MD5 as well -- and, because of point #4 above, the Web will be even fuller of MD5.

Note that in most cases, there is no urgency to replace MD5. MD5 is completely broken with regards to collisions, but it is still (almost) as good as new for preimages; also, it seems still fine for use in HMAC and derivatives (including PBKDF2). Collisions are not an issue in many case (and this includes password hashing; the problem of MD5 for password hashing is not collisions, but speed). So while MD5 is quite past its prime and shall not be used for new applications, a lot of existing usages of MD5 are still reasonably robust and do not warrant emergency update. Do not panic.

  • 1
    i think an algorithm that some weakness is found in it should be considered much more prone to other weaknesses that may be found in the future (specially if it is still used widely). so it's better to not use it at all when there r alternatives with sufficient support and convenience.
    – H M
    Commented Mar 23, 2013 at 20:59
  • 2
    This should not be the "normal" development method ... if it is you have more to be concerned about than using MD5's for your hash. Copying and pasting random code from the internet and testing if it seems to work is a sign of an under-experienced developer working on things they shouldn't be especially if it's going into production.
    – Nick
    Commented Mar 24, 2013 at 0:47

Old habits die hard. Some people are not aware or don't care that md5 is broken. There are also cases where using md5 isn't a vulnerability. md5 could be used for data consistency or generate random numbers.


I think MD5 is still used for computing checksums and validating data. But MD5 and SHA-1 are not good candidates for hashing passwords. They are fast to compute, and finding collisions is not that hard of a task anymore.

  • 1
    But finding collisions is irrelevant for password hashing, and iterated+salted md5 isn't much weaker than PBKDF2-HMAC-SHA2. Commented Mar 23, 2013 at 20:07

MD5 is still perfectly fine if you don't care about collisions in your use case.

If a consultant advices you to change MD5 to something else, even though your application does not care about collision attacks (or the fast speed of computation), then you should hire another consultant because he doesn't know what he is talking about.

It is surprising how many people in the 'security industry' do not know the difference between collision attacks, pre-image attacks and second pre-image attacks.

  • Actually I disagree, considering that for storing passwords you should always take a hash which is fast in software but slow on hardware. MD5 is therefore not suited for storing passwords. If it's in a PBKDF2 implementation we can argue, but just password+salt is definitely not desirable. Commented Mar 23, 2013 at 22:40
  • I didn't say anything different - where is the disagreement? I mentioned that if you don't care about the speed of computation (MD5 being too fast on the attacker's side) then its fine to use it. [ so I exclude password hashing use cases ]
    – AnroidSec
    Commented Mar 23, 2013 at 23:20
  • is it safe to use md5 for combining/mixing cryptographic keys? (keys generated by a CSPRNG)
    – H M
    Commented Mar 24, 2013 at 5:52
  • 1
    The pattern in cryptography has long been that once a flaw in an algorithm is found, it tends to open up other flaws, as if a crack develops. For certain uses MD5 is fine, namely when there's no real attack threat. But I'd still advise people to choose a different algorithm that hasn't found attacks on it. Commented Feb 10, 2015 at 22:19

Older software may also retain MD5 for compatibility reasons. I.e. older versions of the software has used MD5 in data and/or communication protocols (due to ignorance, or because MD5 was still considered secure at the time when the software was written). Now the newer version has to support MD5 at least for backwards compatibility.

They may also want to avoid the cost of upgrading file formats / communication protocols to support more modern hashes, or even explicitly retain forward compatibility of the older version of the software.


I've typed 'linux checksum' in google, and 1st and 3rd hit have 'md5' in title. Browsing for examples gives you the same. You have old manuals, old tutorials, and a lot of old open-source programs, which are used as basis for people learning PHP. Unix flavours have md5 command, databases have md5 function etc.

Note that very many PHP developers are self-learners, without academic background, so the examples are the way they learn. After a few months you can even consider MD5 and checksum as synonyms.

Actually, you should be happy that so many developers are using MD5 because the alternative could storing password plain text. My collegue was working in one project (publicly available site) and he discovered that passwords were stored plaintext! It's a real-life example how poor the security perception is.

  • 3
    MD5 is 'okay' for checksums; it's still very hard to find a collision and modify the software without modifying the md5 checksum. Unsalted passwords on the other hand...
    – Luc
    Commented Mar 24, 2013 at 12:57
  • yes, but if you already have a hammer, and checksum is hash, and you need to hash something... the result is quite predictable
    – user9850
    Commented Mar 24, 2013 at 13:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .