So... how do databases really store your password? 🔑

let's imagine you are a pentester (assuming you are a good person). you got somehow access to the database and now you can see all users stored...

when you query the users table you see:

id | username | password
---|----------|----------
1  | john     | $2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi
2  | jane     | $2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi
...

now simple passwords like password or 123456 or qwerty are shown as gibberish. and now the passwords look useless. but is it really?

this is exactly why all serious companies protect their passwords.

so let's see how this works.

Hashing

imagine you have some ingredients like a password and you blend + cook those ingredients together. can you get the ingredients back if you only have the final dish? ❌

that’s what a hashing function does. it takes the password and produces a fixed-length string of characters, called a hash. the hash is unique to the password and cannot be reversed to retrieve the original password.

same input => same output
password => $2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi

so now when users create accounts, the passwords are not stored directly. they are hashed first, then stored. think of it as secure fingerprint storage.

how it works (signup vs login)

flowchart TD
    A[user enters password (signup)] --> B[Server hashes password]
    B --> C[Store hash in database]
 
    D[user enters password (login)] --> E[Server hashes input]
    E --> F{Compare with stored hash}
    F -->|Match| G[Login Success ✅]
    F -->|No Match| H[Login Failed ❌]

but a problem: if users choose weak passwords, attackers can still guess. using precomputed tables called Rainbow Tables 🌈. that’s what happened to LinkedIn when they used unsalted SHA-1. plain hashing is not enough.

Salting 🧂

a salt is just a random string of characters added to the password before hashing. this makes rainbow tables useless.

example:

password123 + salt123 => $2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi

even if two users pick the same password, their stored hashes will be different. rainbow tables are now ineffective. attackers will try brute force with password lists like rockyou.txt instead.

Adaptive Hashing Algorithms 🛡️

this is why big companies use algorithms like bcrypt, scrypt, or argon2. they are designed to be slow and resource-intensive.

• you can configure the cost factor (how many rounds).
• e.g. bcrypt with 12 rounds may take 100ms to hash one password. nothing for a login, but a nightmare for brute force.

OWASP recommends using adaptive hashing like bcrypt, scrypt, or argon2 to slow attackers down.

Pepper 🌶️

a pepper is a secret value stored outside the database, maybe in a hardware security module (HSM) or secure enclave.

hash = Hashing(password + salt + pepper)

Google and Amazon mention using these techniques. even if DB is stolen, without the pepper it’s harder to crack.

What security is enough?

👉 the answer is OWASP rules:

• always assume your database will be stolen one day.
• never store plaintext passwords ❌.
• always use adaptive hashing algorithms ✅.
• always use a unique salt 🧂.
• add pepper if possible 🌶️.

all of this effort is because we still rely on passwords. but big tech is moving away → biometrics, passkeys, and passwordless auth 🔑✨.

👉 in the next sooner i’ll break down passkeys and how they may end the password era.