It's a look up table operation vs. a per-item computation, essentially. If you have passwords hashed using md5 and no salt then you just go get a giant pre-com

It's a look up table operation vs. a per-item computation, essentially. If you have passwords hashed using md5 and no salt then you just go get a giant pre-computed library of hashes and you go through each hash and figure out if it's in your library. This is EXTREMELY fast, and with modern computing power and memory/storage capacities these libraries can be huge and won't just include things like common passwords and dictionary words but also random strings of characters up to fairly long lengths. With this sort of attack you just filter the list of hashes through your table and you end up with a list of passwords. The important thing about un-salted hashes is that no matter how much work is put into building the table it's amortized over the total number of passwords attacked, over all time. Which drastically lowers the amount of effort per password. With a per-entry salt this sort of attack is no longer possible. Instead you are forced to do a brute force attack on each and every password. If, hypothetically, it took a week to generate a really good rainbow table then it would take essentially just one week to crack nearly 860,000 passwords. Whereas with unique salts it would take 860,000 weeks. However, that's only in the hypothetical case. In practice many people have weak passwords, and a well-built system can compute a huge number of md5 hashes per second. Someone built a multi-GPU monster system that could compute 180 billion md5 hashes per second while only taking up about half of a standard server rack of space (5x 4U). So if you toss an extremely large dictionary of password guesses with even millions or tens of millions of entries it will still take only a fraction of a second to check each hash, so you can crack a significant number of passwords (at leas the ones that aren't incredibly strong) in only a matter of days.