🧱 Why You Should Never Store Actual Passwords
Storing the actual password (even encrypted) creates massive risks:
❗ Problem 1: If the database is compromised, all user accounts are compromised
-
Even if passwords are encrypted, they can often be decrypted (because encryption is reversible).
-
Attackers who get your encryption key can recover every user’s password.
🔐 Hashing = One-Way Street
-
With hashing, even if someone steals your database, they can’t get back the original password.
-
Because hashing is non-reversible by design.
Example:
User’s password: qwerty123
You store: SHA256("qwerty123") = b1f6...
No matter what — you can’t “unhash” that value.
💥 But What If Two Users Use the Same Password?
Good catch — that’s why we salt passwords:
salt = random(16 bytes)
hash = SHA256(salt + password)
store: [salt, hash]Now even if two users use "qwerty123", they’ll have different stored hashes.
🔄 Why Not Just Encrypt Passwords?
Even if you encrypt passwords:
-
Someone who steals your database + key can decrypt them.
-
Passwords can be exposed by accident (e.g., logging decrypted values).
-
It violates the principle of least privilege: you shouldn’t need to know the password, only whether it matches.
🔑 TL;DR – Always Hash Passwords Because:
| 🔥 Risk | 🔐 Solution |
|---|---|
| Users reuse passwords | Hashing protects them from reuse leaks |
| Database leaks | Hashed values are useless to attackers |
| Insider threat | You (the dev) shouldn’t know users’ passwords |
| Legal compliance | GDPR, HIPAA, etc. require best practices like hashing |