What a hash function actually guarantees
A cryptographic hash function takes input of any size and produces a fixed-length digest — 128 bits for MD5, 160 for SHA-1, 256 for SHA-256 — with three properties that matter in practice:
- Deterministic: the same input always produces the same output.
- One-way: it's computationally infeasible to reconstruct the input from the digest.
- Collision-resistant: it should be infeasible to find two different inputs that produce the same digest.
That third property is exactly what's broken in MD5 and SHA-1, and it's why they're deprecated for anything security-related — despite still being useful for non-security purposes.
SHA-256("hello") = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
MD5("hello") = 5d41402abc4b2a76b9719d911017c592
Flip a single character and the entire output changes unpredictably — this is the avalanche effect, and it's what makes hashes useful for integrity checks: any modification, however small, produces a completely different digest.
MD5 and SHA-1: retired, not just "old"
MD5 (1992, 128-bit) and SHA-1 (1995, 160-bit) are not merely outdated — they have practical, demonstrated collision attacks. Researchers have produced two different files with identical MD5 hashes, and Google demonstrated a real SHA-1 collision (the "SHAttered" attack) in 2017. This means an attacker can craft a malicious file that hashes identically to a legitimate one, defeating integrity checks that rely on either algorithm. Neither should be used for signatures, certificates, or anything where an adversary might deliberately engineer a collision.
They're still fine for non-adversarial use: checking whether a downloaded file got corrupted in transit, deduplicating identical files, or generating a quick cache key — situations where nobody is trying to construct a matching collision on purpose.
SHA-256 and the SHA-2 family
SHA-256 (part of the SHA-2 family, alongside SHA-224, SHA-384, and SHA-512) has no known practical collision attack and is the current standard for integrity verification, digital signatures, and blockchain applications. The tradeoff for the larger 256-bit output is more compute per hash — negligible for a single file check, more relevant at very high volume.
| Algorithm | Output size | Status | Use today for |
|---|---|---|---|
| MD5 | 128 bits | Broken (security) | Non-security checksums only |
| SHA-1 | 160 bits | Broken (security) | Legacy compatibility only |
| SHA-256 | 256 bits | Secure | File integrity, signatures, general hashing |
| SHA-512 | 512 bits | Secure | Same as SHA-256, higher output size |
Why you should never hash passwords with SHA-256 alone
This is the most common hashing mistake in real systems: SHA-256 is fast — designed to hash gigabytes of data quickly — which is exactly the wrong property for password storage. A fast hash lets an attacker who steals a password database try billions of guesses per second on commodity hardware (or GPUs). Password storage needs a deliberately slow, memory-hard algorithm — bcrypt, scrypt, or Argon2 — that makes brute-forcing computationally expensive even at scale. Plain SHA-256(password) is not meaningfully safer than storing MD5 in this specific context, regardless of SHA-256's general security.
Common mistakes
- Using MD5 or SHA-1 for anything an attacker might target (file signing, certificate fingerprints, deduplication where malicious collisions matter).
- Hashing passwords with a general-purpose hash instead of bcrypt/Argon2, leaving them vulnerable to fast brute-force even without a known collision attack.
- Assuming a hash provides confidentiality. It doesn't — hashes aren't reversible by design, but they also aren't a substitute for encryption if you need to recover the original value later.
- Comparing hashes with
==in a way vulnerable to timing attacks, in security-sensitive contexts (e.g., verifying an HMAC) — use a constant-time comparison instead.
FAQ
Can a hash be reversed to get the original input back?
No — a well-designed hash function is one-way by construction; "cracking" a hash in practice means guessing inputs and hashing them until one matches, not mathematically inverting the function.
Is SHA-256 good enough for password storage?
No — it's too fast, making brute-force attacks practical at scale. Use bcrypt, scrypt, or Argon2, which are deliberately slow and memory-hard.
Why do MD5 and SHA-1 still show up in tools and legacy systems?
Speed and backward compatibility — they're fine for non-adversarial checksums (verifying a download wasn't corrupted), just not for anything where a motivated attacker might engineer a collision.
What does it mean for two inputs to "collide"?
They produce the identical hash digest despite being different inputs — a well-designed hash makes finding such a pair computationally infeasible; MD5 and SHA-1 no longer meet that bar.
Generate and compare MD5, SHA-1, SHA-256, and SHA-512 hashes instantly with the Hash Generator — all processing stays in your browser.