8

First, i should say that I am relatively new to programming so please be gentle with me if this is a naive or dumb question.

Ok, so I am in the process of writing a small application, part of which will involve hashing user passwords. After researching the best way to do this, md5 appears as a suggestion, almost as many times as it appears in articles criticizing its use.

The alternatives are the likes of SHA-1 etc which are stronger and less likely to be cracked. This makes perfect sense.

To get to the point:

  1. Why is md5 still widely used for hashing
  2. Should I automatically discount md5 for hashing passwords, or are there specific use cases where its use would actually be better than other hashing mechanisms?
  • possible duplicate of [PHP can handle 40+ hashing algorithms. So why is md5 the de facto standard?](http://stackoverflow.com/questions/11062597/php-can-handle-40-hashing-algorithms-so-why-is-md5-the-de-facto-standard) – hakre Jun 23 '12 at 10:08

5 Answers5

10

Neither MD5 nor SHA-1 should be used for hashing passwords. They are designed to be fast to compute, which is exactly what you don't want. If people are using these hashing algorithms for hashing passwords, it's likely because they don't know about alternatives.

Instead you should be using something like bcrypt that is designed specifically for this purpose. It can be configured to be as hard to compute as you need. As computers get faster you can just add more rounds to the computation to make it take longer. This will slow down attackers who get hold of the hashes and try to use brute-force or dictionary based attacks to get the passwords.

Related

Community
  • 1
  • 1
Mark Byers
  • 811,555
  • 193
  • 1,581
  • 1,452
  • Thanks Mark. It appears to be the consus among the answers that bcrypt is a better soltuion. I will investigate this as an option. Do you know if there would be performance issues on large traffic websites, using this as an authentication method for its users? –  Jun 23 '12 at 10:12
  • @JohnMoore: There can always be performance issues on large traffic websites regardless of which authentication method you use. Authentication will normally only be a small part of the total server load. – Mark Byers Jun 23 '12 at 10:19
  • this is not a complete answer. if it is as straightforward as you state it, why would apps as widely used as wordpress and joomla use straight md5 hashing for user passwords? i do not know the answer, but am very curious! – giorgio Jun 23 '12 at 10:49
  • 3
    @giorgio: Wordpress allows the administrator to configure which hashing scheme it is used. It uses [phpass](http://www.openwall.com/phpass/) in its implementation (since about [5 years ago](http://core.trac.wordpress.org/ticket/2394)). From the phpass docs: "The preferred (most secure) hashing method supported by phpass is the OpenBSD-style Blowfish-based bcrypt". However I suspect that few people actually bother to read the documentation. – Mark Byers Jun 23 '12 at 11:03
  • More important, always check for a better update. For now argon2 seem to be the better password algorithm see https://security.stackexchange.com/questions/193351/in-2018-what-is-the-recommended-hash-to-store-passwords-bcrypt-scrypt-argon2 – pdem Jan 18 '22 at 16:18
1

For the same reason mysql_* functions are used, most resources and tutorials on the web are outdated with information, causing newbie programmers use them blindly (because the tutorial said so!).

I don't blame the new programmers, I blame the tutorial makers for not updating their tutorials. Google's search algorithm also usually takes age into account, and displays older entries higher in the search result.

As for alternatives, I believe Mark Byers said it better than I can.

Madara's Ghost
  • 172,118
  • 50
  • 264
  • 308
0

Why is md5 still widely used for hashing

It's perfectly fine, if you want to e.g. check a program for validity (md5 your ISO). That some people use it for stuff it shouldn't be used for (anymore) shouldn't be of your concern, and is inanswerable :)

Should I automatically discount it, or are there specific use cases where its use would actually be better than other hashing mechanisms?

Yes. Discount it if you are using it for passwords. You have allready found weaknesses, but see what @markbyers says about what you should use, e.g. bcrypt

Nanne
  • 64,065
  • 16
  • 119
  • 163
  • 1
    Actually for validating large chunks of data (i.e. an ISO) where an attacker also has access to the original ISO, MD5 is _not_ a good choice. This is exactly the right conditions for the known second pre-image attack on MD5 and would allow an attacker to include additional content on the ISO and yet still have it validate. – Alnitak Jun 23 '12 at 10:16
  • 1
    Sure, checking an ISO from an unknown source needs more security. On the other hand, if I have program on my site I add an MD5 to avoid download issues. If an attacker changed my ISO, they sure can also change the mentioned MD5 hash on that same site, so why even bother? Anyway, it was just an example to give one of the reasons why people use it, because that was the question. Never said there weren't any problems with it.... – Nanne Jun 23 '12 at 10:43
  • 1
    that's not the point - the MD5 hashes are often posted separately via a different channel so it's typically not feasible for a hacker to change both the file _and_ the published digest. The point I was trying to make is that MD5 is still (in pure cryptanalysis terms) just as good as it ever was for passwords, but _isn't_ for file validation. The only thing that has changed w.r.t. password validation is that Moore's law now makes it feasible to brute force test millions of passwords per second. – Alnitak Jun 23 '12 at 10:52
0

Why is md5 still widely used for hashing?

It is not. Even Wordpress abandoned it years ago. And Wordpress is widely used.

Should I automatically discount it, or are there specific use cases where its use would actually be better than other hashing mechanisms?

I have no clue what you mean. Use a hashing algorithm that suitable for password hashing and you should not need to worry much.

Community
  • 1
  • 1
hakre
  • 193,403
  • 52
  • 435
  • 836
0

MD5 is still reasonably safe to use for most cases[*], so long as you use a good "salt" to mix in with the actual password before it's encrypted.

There is still no known way other than brute force to accomplish a "first pre-image attack" on MD5, i.e. given a hash, figure out what the original password was.

The "salt" mentioned above is necessary to ensure that your encrypted passwords can't be trivially looked up in a "rainbow table" or other existing lists of "string to digest".

The recent Linked-In password leak is a good example of why salt is important. They failed to salt their users' passwords, so many of the passwords were trivially reversed because the hashes of those passwords are already computed (and in many cases found via Google).

What you still shouldn't do though is have the salt itself easily determined. If the attacker can work out what the salt is all bets are off, because then the brute force mechanisms described in the article posted by Florian become available again. A good salt should be long, and you shouldn't use the same salt for every user.

The only true weaknesses so far found in MD5 itself have been ways to produce a new file which manages to result in the same MD5 digest as another file, when you already know the contents of the original file. This is known as a "second pre-image attack", and is irrelevant when considering the use of a hashing algorithm for password encryption.

All that said, if a better algorithm (SHA-2, bcrypt) is available, you might as well use it!

[*] I wouldn't use MD5 for anything relating to eCommerce, though!

Alnitak
  • 334,560
  • 70
  • 407
  • 495
  • 1
    MD5 is not safe for anything security-related any more. Especially not passwords. Even if no flaws had been found in MD5, it would still not be appropriate for passwords because it's far too fast. [Salt would **not** have saved LinkedIn](http://security.stackexchange.com/q/15910/1472). These days it's faster to brute force an MD5 (or SHA1) password than to read the rainbow table off the disk. The LinkedIn hashes were already de-duped before being leaked which couldn't have happened if salt had been used. The SHA2 family is too fast. Use bcrypt, scrypt or PBKDF2. – Ladadadada Jun 23 '12 at 13:05
  • 1
    @Ladadadada Sure, use bcrypt, scrypt, whatever, I agree that all that is best practise. But the fact remains that with a properly random salt (say 256 bits) where each password has a different salt and is unknown to the hacker it would _still_ take longer than the lifetime of the universe to brute force MD5 even with every NVidia card ever made. It would be far faster to brute force the password login at 1 attempt per second than to brute force the hash. And most of the comments on the answer you linked to appear to agree with that. – Alnitak Jun 23 '12 at 13:50
  • Checking the entire keyspace of MD5, sure, longer than the lifetime of the universe. Checking 8 characters of the entire printable ASCII set as MD5? 35 days with a single Radeon HD 5830 for $170 [using this table](http://golubev.com/gpuest.htm). And probably half that on average to find the password. Salt doesn't change the time taken to check a single password (unless it's big enough that disk access is the bottleneck). It only forces each password to be cracked individually. And please explain how 1 attempt per second can be faster than 3.3 billion per second? – Ladadadada Jun 23 '12 at 15:58
  • @Ladadadada you've ignored the whole thing about 256 bits of _extra_ entropy that I suggested - that's plenty enough to make even 3.3 billion checks per second dozens of orders of magnitude too slow. _Unknown_ salt absolutely does increase the time to check the password - what you've said only applies if you do know what the salt is. Brute forcing the login screen can be faster than brute forcing the hash because by definition you don't then need to guess the salt - the login screen does that for you. – Alnitak Jun 23 '12 at 16:58
  • Unknown salt? How does your attacker compromise the hashes without also getting the salt? – Ladadadada Jun 23 '12 at 22:46
  • @Ladadadada the salt doesn't have be stored with (or in) the hashes. – Alnitak Jun 24 '12 at 06:29
  • 2
    *Unknown hashes* would be a much better bet. Why not just keep *them* secret instead of the salt? Wherever you store the salt, you need it and the hash to log users in so they both must be easily accessible. You have to assume that if the attacker can get your hashes, he can get your salt. If you could stop him getting your salt, you could do the same thing for the hashes. What you have described is essentially *encrypting* the passwords rather than hashing them and calling your key *salt*. Now your problem is key management. – Ladadadada Jun 24 '12 at 08:03