There are levels of vulnerability:
1: Vulnerability to a pre-computed table. This hits hard if you are using plain-old MD5 without a salt.
2: Vulnerability to a newly computed table. This will hit you if you use a global salt and a fast hashing/encryption algorithm.
3: Vulnerability to high throughput custom hardware. This will hit you if you use a fast hashing algorithm like MD5. Modern GPU-based algorithms can churn through hundreds of billions of hashes per second on fairly inexpensive hardware. Which means that attacking, say, 20 million accounts it's possible to run through billions of possible passwords (which means a full dictionary attack, the top million most common passwords, plus common ways of combining words to make passwords, plus every random alphanum string up to 9-10 digits) for each and every account in only a month of work.
4: Vulnerability to very weak passwords. This will hit you if you use a slow hashing algorithm and there's no global vulnerability because you use per-record salts (or bcrypt/scrypt).
4 is where you want to be, always. You can't protect against weak passwords, but you can make it expensive for weak passwords to be revealed, and prohibitively expensive for stronger passwords to be systematically cracked.
The entropy of the hashes isn't really relevant since it's the repeatability of the hashing that's at issue. For example, the hash 7c6a180b36896a0a8c02787eeafb0e4c seems to have plenty of entropy, but since it's the MD5 of the string "password1" and you can just google that hash to find out that information, the theoretical entropy is moot.