Why fast hashes are dangerous for password storage
MD5 and SHA-1 fall to a GPU in seconds because they are fast and often unsalted. Learn why slow KDFs like bcrypt and Argon2 resist — and what defenders should do.
Not all hashes are equal targets. The single biggest factor in whether a stolen password database is cracked in an afternoon or stays safe for years is the speed of the hashing algorithm. This sounds backwards — surely fast is good? — but for password storage, fast is exactly the problem.
Speed is the attacker's friend
A cryptographic hash like MD5 or SHA-1 was designed to be fast: to verify a file or sign a message you want the digest computed instantly. That same speed is a gift to an attacker. A modern GPU computes billions of MD5 hashes per second. When the algorithm is fast, the bottleneck disappears, and the attacker is limited only by how many guesses they can generate.
Make it worse by leaving the hash unsalted, and two things happen. First, identical passwords produce identical digests, so cracking one account cracks every account that reused the password. Second, the attacker can use precomputed rainbow tables — vast lookup files that trade storage for instant reversal of common digests. An unsalted MD5 of a weak password is, in practice, already broken before the attack even starts.
hashcat -m 0 -a 0 dump.txt rockyou.txt
Point that at a list of unsalted MD5 hashes and the common passwords fall in seconds.
Salts help, but they are not enough
Adding a salt — a unique random value mixed into each password before hashing — fixes the rainbow-table problem. Every digest becomes unique, precomputation is useless, and the attacker must attack each hash individually. That is a genuine improvement. But a salt does not slow down a single guess. Against salted-but-fast MD5, the GPU still rips through billions of attempts per second; the attacker has simply lost the shortcut, not the speed.
Slow, memory-hard KDFs resist by design
The real defence is to make each guess expensive on purpose. Password-hashing functions like bcrypt, sha512crypt, md5crypt and the modern Argon2 are key derivation functions built around a tunable cost factor. Instead of one fast operation they perform thousands of iterations, and Argon2 also demands large amounts of memory, which neutralises a GPU's parallelism.
A bcrypt hash at cost 12 might take a quarter of a second to compute. That is invisible to a user logging in, but it collapses an attacker's throughput from billions per second to a few thousand. The same wordlist that empties an MD5 dump in seconds would take centuries against well-tuned bcrypt.
Takeaways for defenders
If you store passwords, the rules are short. Never use raw MD5 or SHA-1 for credentials. Always salt — but treat the salt as table stakes, not a solution. Choose a slow, memory-hard KDF (Argon2id where you can, bcrypt or sha512crypt otherwise) and raise the cost factor as hardware gets faster. When you need to confirm what algorithm a leaked hash actually uses, the hash type index and the earlier guide on identifying an unknown hash will tell you in seconds — privately, in your browser.