The vulnerability is "not using a password hash construction", of which the best known are bcrypt and PBKDF2.
You could slap MD5 into PBKDF2 with a high iteration count and achieve comparable security. The problem is that devs often use a hash function a single time.
Password hash constructions do more than simply run the hash function multiple times.
We are, obviously, saying much the same thing.
Again: the key point here is, don't DIY this part of your application.
If you don't have a reasonable salt then you're vulnerable to time/space tradeoff attacks like rainbow tables/etc.
Also, in case you haven't used it. Scrypt is pretty damn awesome. It's designed to be memory hard, which makes it very hard to crack even with GPUs.
"Huge" being the key word here.
Try searching for the md5sums of arbitrary 8-character alphanumeric passwords. You won't find many results. 62^8 is a big number.
The currently available databases are surprisingly large, even if not in the scale of 62^8. Consider a random pick from decrypt.fr: "phytostrote972". It's far from a random string, but not exactly a trivial one either.
A HD 5870 can churn through MD5s at about 2.8 billion/sec - 62^8 inside 24 hours on a single unremarkable GPU.
8-character alphanumeric are the ones that are being offered today, it's only going to go up as GPUs get better and HD space/bandwidth increases.
Hence the current advice is to use "alongpassphraseasyourpassword" rather than "L33$Pa55wd"
Why? Is it not being hashed? I have a (possibly very wrong) inkling that a longer phrase might increase the chance of collision but even so, so many places enforce a strong password but force you to keep it short.
You need a fairly expensive SAN to pull 1Billion MD5 hashes/second just from the raw disk - nevermind the DB lookup.