It's not the weakest algorithm, but for all intents and purposes it has indeed been "cracked", rendering it virtually useless.

Indeed, when you add a salt, it would be a lot more secure because then normal rainbow attacks don't work anymore -- the attacker has to create a new rainbow table for each salt, which is near impossible.

That said, if you have a chance to switch to a different algorithm like SHA1, I'd definitely do that!

Also, you may want to take a look at phpass (which uses either SHA1 or blowfish, depending on the capabilities of the system).

It's not the weakest algorithm, but for all intents and purposes it has indeed been "cracked", rendering it virtually useless.

That it has been cracked makes no difference if you are using it for the purpose for which hashes were originally intended - where the original content and the hash are both accessible with the hash being used to determine if the original has been tampered with - since a small change to the original results in a completely different hash. Being able to tamper with the original in such a way that it is still meaningful but presents different information and still produces the same hash is still impossible with MD5. So it isn't useless, it is still as effective for its intended use as it ever was.

It is only when you use it for purposes for which MD5 was never intended to be used in the first place that it having been 'cracked' makes any difference.

On 30 December 2008, a group of researchers announced at the 25th Chaos Communication Congress how they had used MD5 collisions to create an intermediate certificate authority certificate which appeared to be legitimate when checked via its MD5 hash.

Maybe 'useless' was a bit an overstatement, but I for one am staying clear from md5 and have switched to sha1 and blowfish.

If I use MD5 to store passwords with a strong SALT value, would the passwords be still unsecured?

The passwords would be secure. MD5's collision resistance is broken, but securing passwords doesn't rely on collision resistance. That being said, switching to a better hash algorithm is incredibly easy. There's no reason not to switch.

As it has been mentioned, you should always apply a salt when hashing a password. The longer the salt is the better.

While it is correct that it is easier to locate a collision in a md5 hash these days, the approach used to do this does not make it easier to "locate" the content used to create the hash. I.e. recreate the content.

To be honest, we have known for something between 16-20 years that md5 is not collision safe, but for the use of "hashing" passwords together with a good salt it was more than safe enough.

The problem even today is not the collisions, but the fact that with some new Nvidia videocards put in SLI and a program made in CUDA you can get immense processing power quite cheap, that only the largest universities had only a decade ago. Heck even Amazon allow you to rent number crunching servers by the hour. This means that if a malicious user get a hold of your md5 password hashes, brute forcing one of them will be "almost instant" compared to doing the same on your computer a decade ago.

A md5 password hash perhaps on 6-8 characters, you brute force in a few min with the right hardware/software today. Even with a good salt added on, you can normally crack them in a few hours max.

Instead of using md5 I would recommend either whirlpool or sha512, both with are 512bit. There is no reason to use lower hashing algorithms these days, as you dont check the password on every page load for example. Note, if your unfamiliar with it, take a look on the hash() function in php.

I think "almost instant" needs to be clarified. If you could compute 8 billion hashes per second, it would still take you about 700 quintillion years.

Well, "almost instant" was just used to point out the differences of the computer power you as a end user can possess today, that was only available for larger companies and universities only a decade ago.

Without sitting down and crunching numbers, I'm certain that your overestimating the number of available md5 hashes.

In addition what you need to keep in mind is that md5 (and other hashes) was created to validate data integrity, i.e. verify that the content of a file/text has not been tampered with. This means that when dealing with password hashes created by md5, even when they contain a salt, does not mean I need to "check" the entire available range of hashes.

Just as you would not try to "brute force" a md5 data integrity hash to "unzip" the file, you wont start with a 2mb file with text when brute forcing working your way downwards to find a match.

Without sitting down and crunching numbers, I'm certain that your overestimating the number of available md5 hashes.

It's actually pretty simple math. Total number of hashes (2^128) divided by hashes per second (8 billion) divided by seconds per minute, minutes per hour, hours per day, days per year. I even divided the final number by 2, since on average you'll find the correct result after searching only half the hashes.

TheRedDevil said:

...when dealing with password hashes created by md5, even when they contain a salt, does not mean I need to "check" the entire available range of hashes.

You're talking about brute forcing the password rather than brute forcing the hash, and you're right, that definitely reduces the number of possibilities to check. But the same is true for any hash algorithm, because in this scenario, it's the password that's the weak link, not the hash.