Yes, it matters. A lot. Salted means you have to crack each password individually. You have to run through the entire list of candidates (until a match) for each and every salted password (given unique salts). With unsalted passwords you can run through the wordlist once, and get all matching passwords with a single MD5 run for each word in your wordlist. It doesn't matter for one single password, but for 60000 salting means 60000 times more work. And salting renders rainbow tables useless, because you'd have to build one rainbow table for each possible salt.
Thanks for this explanation. For implementation purposes, how would a website use a unique salt? For example, when the username types in a password it must be joined to the salt and then an MD5 algorithm ran over the product to compare with the database stored hash.
Somewhere then the salt must be stored, right?
Random, and yes, it is stored.
If the hash started with $, it follows this format:
$<scheme, always 1 here>$<salt>$<hash>. Scheme 1 means about 1001 rounds of MD5 with complex combinations of the previous round, the password, and the salt.
Other schemes are available for SHA, blowfish, and (try not to laugh) NT.
If it doesn't start with $, it is just a simple unsalted MD5 hash of the input.
