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).
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.
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.
One more interesting answer and comments :
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.
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.
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...
My 0.02$ :
1. even though I wouldn't recommend using the plain-old MD5 for password hashing (I guess there are better up-to-date methods today), I have the feeling that the Internetz are full of misunderstanding (and quite a load of bullsh*t) when it comes to "MD5 is broken"... (read links / comments above)
2. whatever hashing method is used, the length of the input doesn't matter : all hashed passwords will have the same length anyway, and can be stored easily in a "char(n)" database table column (with n = length of the hash). Which means websites / applications displaying warnings such as "Your password should be between 8 and 16 characters long" should really be considered as PURE EVIL : such warning _could_ mean the passwords are stored as clear text...