Password Hashing vs Encryption
Passwords should never be stored encrypted — they should be hashed. But most developers confuse the two. Here is the critical difference and why it matters for user security.
The key difference
| Property | Hashing | Encryption |
|---|---|---|
| Reversible? | No (one-way) | Yes (with key) |
| Key required? | No | Yes |
| Use for passwords? | YES | NO |
| Use for sensitive data? | No (irreversible) | Yes (AES-256 etc.) |
| Algorithm examples | bcrypt, Argon2, SHA-256 | AES-256, RSA, ChaCha20 |
Why passwords must be hashed, not encrypted
If you encrypt passwords, anyone with the encryption key can decrypt and read all passwords. If a server stores bcrypt hashes, even a full database breach exposes no usable passwords — cracking bcrypt is computationally infeasible with a strong salt.
SHA-256 is a secure general-purpose hash but is too fast for passwords — use bcrypt, Argon2, or scrypt instead, which are deliberately slow to resist brute-force attacks.
When to use encryption
- Storing recoverable sensitive data (credit cards, API keys) — AES-256-GCM
- Data in transit — TLS/HTTPS handles this automatically
- File encryption — use AES-256 with a strong key
- Note: you still hash the password used to derive the encryption key
Frequently Asked Questions
Is MD5 safe for password hashing?
No. MD5 is fast and has known collision vulnerabilities. For passwords, use bcrypt, Argon2id, or scrypt exclusively.
What is salting?
A salt is a unique random value added to each password before hashing. It prevents rainbow table attacks and ensures two users with the same password have different hashes.
Can I use SHA-256 for passwords?
Not directly — SHA-256 is too fast. Attackers can compute billions of SHA-256 hashes per second. Use a slow algorithm like bcrypt with at least 12 rounds.