Speed is the problem. ocl-hashcat can test in the region of 6 billion MD5 hashes a second on a decent GPU. With a random salt and, say, an 8 character password it&#x27;d take a long time, but not so long it&#x27;s impossible. On a site that includes rules like &#x27;Must have an uppercase letter&#x27;, &#x27;Must include a number&#x27;, and &#x27;Must include a special character&#x27; you actually reduce the size of the space and consequently make the password easier to brute force. With those rules in place there&#x27;s 159,655,911,367,680 possible passwords[1], so brute forcing at 6 billion hashes a second it&#x27;d take just over 7 hours. Maybe double that for the overhead of adding in the salt and managing the list of attempts, etc.<p>The point is it&#x27;s achievable. If someone gets a dump of the database it can be turned back in to usable accounts. If you use something much slower they can&#x27;t. There&#x27;s no benefit to using MD5. On the other hand, using a better hashing algorithm protects user&#x27;s passwords from brute force attacks. Why wouldn&#x27;t you want that?<p>Quite a good article about cracking a well designed database of bcrypt&#x27;d passwords - <a href="http:&#x2F;&#x2F;arstechnica.com&#x2F;security&#x2F;2015&#x2F;08&#x2F;cracking-all-hacked-ashley-madison-passwords-could-take-a-lifetime&#x2F;" rel="nofollow">http:&#x2F;&#x2F;arstechnica.com&#x2F;security&#x2F;2015&#x2F;08&#x2F;cracking-all-hacked-...</a><p>[1] From <a href="http:&#x2F;&#x2F;math.stackexchange.com&#x2F;a&#x2F;410885" rel="nofollow">http:&#x2F;&#x2F;math.stackexchange.com&#x2F;a&#x2F;410885</a>