In 2022, an Indian payment gateway suffered a breach that exposed millions of user passwords. The problem? They stored passwords with MD5 hashing — a method considered broken since 2005 — and without proper salting. Hackers cracked the entire database in hours.
This wasn’t a “genius hacker” story. It was a basic failure in handling encryption keys and passwords — the kind of mistake that still happens in 2025, from small startups to billion-dollar companies. And here’s the scary part: it only takes one bad decision to turn secure access into an open door.
The Two Layers of Password Security
When you log into a website, there are two things keeping you safe:
- Password encryption or hashing — so your password isn’t stored in plain text.
- Database encryption keys — the secret ingredients that can decrypt sensitive data.
If either is mishandled, your security is gone.
Hashing vs. Encryption for Passwords
- Hashing: A one-way function. Once hashed, it’s supposed to be impossible to reverse. Good for passwords.
Example algorithms: bcrypt, scrypt, Argon2. - Encryption: Two-way — can be decrypted with the right key. Good for data you need to read again (like credit card numbers).
Golden rule: Never store raw passwords, and never encrypt them with a reversible key unless absolutely necessary.
When a company stores hashed passwords with strong algorithms and unique salts, even a database breach can leave hackers with nothing usable.
Why Keys Are the Real Crown Jewels
Encryption algorithms are public — the security lies in the key. If you leak your database encryption key:
- Encrypted data is instantly readable.
- All your careful encryption work becomes irrelevant.
This is why key management is its own field. Services like AWS KMS or Azure Key Vault exist for a reason — to separate your keys from your data.
Common Mistakes That Wreck Security
1. Storing Keys in the Same Database
If your encrypted customer info and the key to decrypt it live side-by-side, a breach of one is a breach of both.
Better: Store keys in a dedicated key vault or hardware security module (HSM).
2. Using Outdated Algorithms
MD5, SHA-1, and even unsalted SHA-256 are too weak for password hashing today.
Better: Use bcrypt, Argon2, or scrypt — algorithms designed to be slow, making brute-force attacks costly.
3. No Salting
Without a salt (random value added before hashing), attackers can use precomputed “rainbow tables” to crack passwords quickly.
Better: Always generate a unique salt for each password.
4. Hardcoding Keys in Source Code
If a developer commits code to GitHub with a database key inside, that key might live online forever — even after deletion.
Better: Store keys in environment variables or secure vaults, never in code.
5. Skipping Key Rotation
Keys should be replaced periodically, especially after suspected compromise. Many breaches stay undetected for months — if you rotate keys regularly, old stolen data may become useless.
Real-World Breach Examples
- Adobe (2013): Stored passwords with symmetric encryption and no salting. Hackers decrypted millions.
- RockYou (2009): Stored passwords in plain text. Breach exposed 32 million accounts, and the leaked dataset is still used for password cracking today.
- LastPass (2022): Hackers accessed encrypted vault data but couldn’t decrypt it because the master password and key never left user devices. Good encryption and key handling saved them.
How to Get It Right in 2025
- Pick the right algorithm — Argon2id is a solid choice for password hashing.
- Separate your keys — Use a KMS or HSM.
- Enforce strong passwords — Long and unique beats complex-but-short.
- Enable multi-factor authentication — So even stolen passwords aren’t enough.
- Monitor for breaches — Use services like Have I Been Pwned to check for exposed accounts.
The Developer’s Checklist
- All passwords hashed, not encrypted.
- Strong, slow hashing algorithm with salts.
- Keys stored outside application code.
- Key rotation policy in place.
- Access to keys restricted to the smallest possible group.
If even one box stays unchecked, your security is relying on luck.
Why This Matters Even for Small Businesses
A small medical practice might think, “Who would target us?” But attacks aren’t always targeted. Automated scripts scan the internet for vulnerable databases. If yours has weak key management, you’re just as likely to end up in a breach dump as a Fortune 500 company.
And in regulated industries, losing control of passwords or keys can mean six-figure fines — not just bad press.
Bottom Line
Password encryption and database keys aren’t “set-and-forget” items. They’re living parts of your security ecosystem, and mishandling them is like locking your front door but leaving the key under the welcome mat.
The good news? The right hashing methods, key storage, and rotation policies can make your access control nearly breach-proof — even when the database itself isn’t.
FAQs
Q1: Should I encrypt or hash passwords?
Hash them. Encryption is reversible and shouldn’t be used for passwords unless absolutely necessary.
Q2: Where should I store encryption keys?
In a dedicated key management service or hardware security module, separate from the encrypted data.
Q3: How often should I rotate encryption keys?
At least annually, and immediately after any suspected compromise.
Q4: Is SHA-256 enough for password hashing?
Not without a salt and ideally a slow hashing mechanism like bcrypt or Argon2.
Q5: What’s the single biggest mistake companies make with passwords?
Storing them in a reversible form or alongside the keys that unlock them.
