Why MD5/SHA-1 Are Still Used but Not for Security — Hash vs HMAC vs CRC32
It's confusing to hear "MD5 is broken" and then still see MD5 checksums posted on download pages. If it's broken, why is it still used? The answer hinges on what "broken" actually means here — MD5 and SHA-1 have been defeated against exactly one specific kind of attack, and for uses where that attack doesn't matter, they're still used without issue.
1. What a "collision attack" actually breaks
One of the core security requirements of a hash function is collision resistance — it should be practically impossible to find two different inputs that produce the same hash value. Research by Wang Xiaoyun and others in 2004–2005 proved MD5's collision resistance broken at a practical level, and in 2008 that break was put to real use: researchers published a rogue certificate authority (CA) certificate built by exploiting an MD5 collision, which sent shockwaves through the field. SHA-1 held out longer, but the situation changed in 2017 when Google and CWI Amsterdam disclosed the "SHAttered" attack — the first publicly demonstrated SHA-1 collision in the world, producing two different PDF files with identical SHA-1 hash values. Following that disclosure, major browsers and certificate authorities stopped issuing SHA-1-based certificates, and systems like Git, which still use SHA-1 for commit identification, have progressively added collision-detection logic or moved toward transitioning to SHA-256.
2. So why is it still used: where "broken" doesn't apply
A collision attack is only a threat when an attacker is deliberately trying to craft two inputs that share the same hash. For uses that are fine as long as "nobody is maliciously tampering with it" — download checksums, accidental-corruption detection, cache key generation, duplicate file detection — MD5 and SHA-1 are still practically safe enough today. In other words, "broken" doesn't mean "unusable for everything," it means "unusable for security purposes under adversarial conditions." Conversely, anywhere an attacker has an incentive to deliberately manipulate a value — password storage, digital signatures, TLS certificates — SHA-256 or stronger is mandatory.
3. A hash and an HMAC are different things
A plain hash function (MD5, SHA-1, SHA-256, etc.) has no secret key. Anyone can compute the same value from the same input, so no matter how perfect its collision resistance is, it can't by itself prove authentication — that "this message really did come from this specific sender." HMAC (Hash-based Message Authentication Code) combines a hash function with a secret key, so only someone who knows that key can produce a correct value. Simply concatenating "secret key + message" and hashing it is vulnerable to a length extension attack, so HMAC uses a nested double-hashing structure with the ipad and opad constants specifically to close off that weakness. In short: a hash guarantees integrity; HMAC guarantees integrity plus authentication.
4. CRC32 was never a cryptographic hash to begin with
CRC32 (cyclic redundancy check) is widely used in Ethernet frames, ZIP files, and PNG chunks, but it was never designed with cryptographic security as a goal. Its sole purpose is detecting accidental transmission or storage errors, and because of its short 32-bit output and its linear mathematical structure, deliberately crafting data with a chosen CRC32 value is practically easy. Using CRC32 anywhere even minimal security is required is a use case outside its original design entirely.
| Type | Security collision resistance | Appropriate use |
|---|---|---|
| MD5 / SHA-1 | Broken (deliberate collisions possible) | Accidental-corruption detection, cache keys, non-security checksums |
| SHA-256 / SHA-512 | Currently secure | Digital signatures, certificates, security-critical integrity checks |
| HMAC (-SHA256, etc.) | Hash + secret-key authentication | API signing, webhook verification, message authentication |
| CRC32 | Not cryptographically designed | Accidental error detection in network/file formats only |
Frequently Asked Questions
Q. Is it okay to store passwords with MD5?
A. No. Password storage has requirements more important than collision resistance — resistance to rainbow tables and brute-force attacks — that make MD5 and SHA-1, and even unsalted SHA-256, all inadequate. You need a purpose-built, deliberately slow algorithm like bcrypt, scrypt, or Argon2.
Q. Is MD5 fine to use as a download-file checksum?
A. If the distributor provides the checksum over a trusted channel (their official site over HTTPS, for example) and the purpose is "confirm no accidental corruption in transit," MD5 is practically fine. But if you need a cryptographic guarantee that "this file has not been tampered with," you need SHA-256 plus a digital signature.
Q. Why does Git still use SHA-1?
A. Git still uses SHA-1 for commit hashes, but since SHAttered it has added collision-detection logic to defend against the attack, and work toward migrating to SHA-256 repositories is ongoing long-term. The odds of an everyday user's routine commit work leading to an actual attack are very low.
Q. Can HMAC use any hash algorithm?
A. In theory yes — HMAC-MD5 and HMAC-SHA1 exist — but in practice, HMAC-SHA256 or stronger is recommended. The HMAC construction itself blocks length extension attacks, but it doesn't fully cancel out other weaknesses (like collisions) in the underlying hash function.