SHA-256 vs MD5 vs Bcrypt
Understanding when to use each hashing algorithm
Quick Answer
- Passwords? → Use bcrypt (or Argon2). Never MD5 or SHA-256.
- File checksums? → Use SHA-256. Fast and collision-resistant.
- Legacy system compatibility? → MD5 for non-security checksums only.
Comparison Table
| Property | MD5 | SHA-256 | Bcrypt |
|---|---|---|---|
| Output length | 128 bits (32 hex) | 256 bits (64 hex) | 60 chars |
| Speed (per sec) | ~10 billion | ~5 billion | ~1,000 |
| Collision-resistant | No (broken) | Yes | Yes |
| Built-in salt | No | No | Yes (128-bit) |
| Adjustable cost | No | No | Yes (2^cost) |
| Password hashing | Never | No | Yes (designed for it) |
| File integrity | Legacy only | Recommended | No |
| Year introduced | 1992 | 2001 | 1999 |
MD5 — Fast but Broken
MD5 produces a 128-bit hash and was designed in 1992 by Ronald Rivest. It was the standard for checksums and password hashing for over a decade. However, MD5 has been cryptographically broken since 2004 — researchers can generate collisions (two different inputs with the same hash) in seconds.
Still acceptable for: Non-security checksums (verifying file downloads), cache keys, deduplication, partitioning. Never use for: Password hashing, digital signatures, certificate verification, or any security-sensitive application.
SHA-256 — Secure and Fast
SHA-256 is part of the SHA-2 family designed by the NSA and published by NIST in 2001. It produces a 256-bit hash and is collision-resistant — no practical collision has ever been found. It's the backbone of Bitcoin mining, TLS certificates, Git commit hashes, and code signing.
Why not for passwords? SHA-256 is designed to be fast — a modern GPU can compute ~5 billion SHA-256 hashes per second. An attacker can brute-force an 8-character password in minutes. Speed is a feature for file verification but a vulnerability for passwords.
Bcrypt — Built for Passwords
Bcrypt is specifically designed for password hashing. Its key features:
- Intentionally slow — ~1,000 hashes/sec vs billions for SHA-256. Makes brute-force impractical.
- Built-in salt — each hash includes a random 128-bit salt, preventing rainbow table attacks.
- Adjustable cost factor — increase the cost as hardware improves. Cost 10 today, cost 14 in five years.
- Self-contained output — the hash string includes algorithm version, cost, salt, and hash. No separate salt storage needed.
$2b$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy ─┬─ ─┬─ ─────────────┬──────────── ──────────┬─────────────── │ │ │ │ │ │ └── 22-char salt └── 31-char hash │ └── cost factor (2^10 = 1024 iterations) └── algorithm version (2b = current)
What About Argon2?
Argon2 won the 2015 Password Hashing Competition and is technically the most secure option. It adds memory-hardness — attackers need large amounts of RAM, making GPU and ASIC attacks much more expensive. Argon2id (the recommended variant) combines GPU-resistance and side-channel resistance.
In practice, bcrypt remains the most widely deployed and battle-tested option. OWASP recommends both bcrypt and Argon2id. If your framework supports Argon2id (like PHP 7.2+, Python passlib, Go), use it. Otherwise, bcrypt with cost 12+ is excellent.
Decision Flowchart
Are you hashing passwords?
→ Yes: Use bcrypt (cost 12+) or Argon2id
→ No: Continue ↓
Do you need collision resistance?
→ Yes: Use SHA-256 (or SHA-3 for future-proofing)
→ No: Continue ↓
Non-security checksum? (cache keys, dedup)
→ MD5 is fine, or use xxHash/CRC32 for even more speed