Introduction
Passwords are the digital keys 🔑 that protect user accounts and sensitive information. Unfortunately, many security breaches happen not because the hackers are genuises, but because the developers stored the passwords incorrectly in the database.
If an attacker ever gains access to your database, you want them to find useless gibberish, not the real passwords. Secure password storage ensures that even in a breach, the attacker gets nothing valuable.
In this article, we will discuss the several techniques which can be used for storing passwords in a database.
1. Storing passwords as plain text (🚫 The Worst Way)
Storing passwords as plain text means saving them exactly as the users type them. Example:
username | password
--------- | ----...Introduction
Passwords are the digital keys 🔑 that protect user accounts and sensitive information. Unfortunately, many security breaches happen not because the hackers are genuises, but because the developers stored the passwords incorrectly in the database.
If an attacker ever gains access to your database, you want them to find useless gibberish, not the real passwords. Secure password storage ensures that even in a breach, the attacker gets nothing valuable.
In this article, we will discuss the several techniques which can be used for storing passwords in a database.
1. Storing passwords as plain text (🚫 The Worst Way)
Storing passwords as plain text means saving them exactly as the users type them. Example:
username | password
--------- | --------
ravi | 123456
neha | 123456
This is a complete disaster! 😱 Anyone with access - hackers, admins and scripts can easily see every password. If the database leaks, all the user accounts are instantly compromised.
Why this approach is bad ⚠:
- Total loss of privacy. 🔒
- Irreversible trust loss and legal risk.
👉 Never ever store passwords in plain text.
2. Simple Hashing (MD5, SHA-1 etc.)
A small improvement is to hash passwords using one way functions like MD5 or SHA-1. Example:
Password: "123456"
MD5 Hash: e10adc3949ba59abbe56e057f20f883e
It looks secure, but it is not. These algorithms are fast and predictable. The hackers can use Rainbow Tables or brute-force attacks to reverse them in seconds.
Why this approach is bad ⚠:
- MD5 and SHA-1 are too fast.
- The precomputed hash tables make reversing easy.
- Identical passwords always produce identical hashes.
Example:
Ravi password = "123456" → MD5 = e10adc3949ba59abbe56e057f20f883e
Neha password = "123456" → MD5 = e10adc3949ba59abbe56e057f20f883e
Attackers instantly know Ravi and Neha share the same password. ➡️ Simple hashing is not enough.
3. Slow Hashing (The Right Kind of Hashing ✅)
Modern systems use slow, adaptive hashing algorithms like bcrypt, scrypt or Argon2. These are specifically designed for passwords and take more time to compute ⌛ —making brute-force attacks painfully slow.
Why slow hashing wins:
- Adjustable cost factor.
- Built-in salting support.
Example:
bcrypt("123456") → $2b$12$Z4qZKZk...
Even if attackers know the algorithm, calculating millions of such hashes takes years, not seconds. 💪
4. Salting
A salt 🧂 is a random string added to each password before hashing. It ensures that even if 2 users have the same password, their hashes are totally different.
Example:
Ravi password = "123456"
Ravi salt = "pqr_salt"
Stored hash = H("123456pqr_salt")
Neha password = "123456"
Neha salt = "xyz_salt"
Stored hash = H("123456xyz_salt")
✨ Result: Different hashes, even for the same password.
Why salting is essential:
- Protects against Rainbow Table attacks.
- Adds uniqueness per user.
The salt is usually stored alongside the hash in the database.
5. Peppering
Peppering 🌶 is like salting, but with a secret twist. A pepper is a secret key added to the password before hashing. Unlike salts, peppers are kept secret and not stored in the database.
There are 2 ways to use pepper:
i) Global Pepper: This means that the same secret will be used for all the passwords. It is stored in the environment variables or any secure config. It is easier to manage and configure. Example:
password + salt + PEPPER_SECRET
ii) Per-user Pepper: This means that a unique pepper will be used for each user. It offers stronger protection, but it is more complex to manage.
Why peppering helps: Even if hackers steal the entire database (hash + salt), they still can’t verify passwords without the hidden pepper.
Conclusion
Storing passwords securely isn’t optional—it’s your duty as a developer. Bad practices like plain text or MD5 are ticking time bombs 💣 waiting to explode in a data breach.
The gold-standard approach includes: ✅ Slow hashing (bcrypt, Argon2) ✅ Unique salting for each password ✅Secret peppering for extra protection
Remember: you’re not just storing passwords—you’re storing user trust 🤝.
And that’s it! This was just a quick overview about how passwords can securely be stored in a database.
Connect with me on LinkedIn :- Linkedin
Do check out my GitHub for amazing projects :- Github