How Databases Keep Passwords Securely 🔒
#61: Break Into Security Fundamentals (3 Minutes)
Get my system design playbook for FREE on newsletter signup:
This post outlines how the database stores passwords securely. You will find references at the bottom of this page if you want to go deeper.
Share this post & I'll send you some rewards for the referrals.
Note: This post is based on my research and may differ from real-world implementation.
Once upon a time, there lived a junior software engineer.
He worked for a tech company named Hooli.
Although he was bright, he never got promoted.
So he was sad and frustrated.
Until one day, he had the idea to apply for a new job.
And the interviewer asked him 1 simple question,
“How to securely store passwords in the database?”.
Yet he failed to answer and the interview was over in 5 minutes.
So he studied it later to fill the knowledge gap.
Onward.
How to Store Passwords in Database
He failed the interview so you don’t have to.
And here’s how you can answer it:
1. Hashing
A hacker can retrieve the passwords easily if they’re stored in plaintext form.
So they transform the password using a hash function.
A hash function creates a unique string value from a password - fingerprint. Also the transformation is one-sided. Put simply, it’s impossible to find the password from a fingerprint.
A popular choice for the hash function is bcrypt because: (1) it’s slow. (2) it needs a ton of computing power. (3) it needs a lot of memory. Thus making it difficult to run many password-cracking attempts for the hacker.
Think of the hash function as mixing colors - it’s difficult to find the original colors from the new color.
Here’s how it works:
The server generates a fingerprint from the given password when the user creates an account.
The password isn’t stored in the database, instead the fingerprint is.
The fingerprint is regenerated whenever the user enters the password.
The regenerated fingerprint gets compared against the value in the database. And the user is given access only if the values are equal.
Ready for the best part?
2. Salting
A hacker might crack the password from the fingerprint using a rainbow table.
So they add salt to the password.
Think of the rainbow table as a map between pre-computed fingerprints and passwords.
While salt is a random string.
And each user gets a unique salt, thus generating different fingerprints. Put simply, 2 users with the same password will have different fingerprints.
Also the rainbow table wouldn’t work after salting because of unique fingerprints. It invalidates the pre-computed values in the rainbow table.
Here’s what happens when the user creates an account:
The server creates a unique salt for the user.
The server combines the salt with the given password and hashes it.
They store the salt alongside the fingerprint in the database.
Here’s what happens when the user enters a password:
The server retrieves the salt for the specific user from the database.
The server combines the entered password with salt to generate a fingerprint.
The server checks if the fingerprints are the same.
Ready for the next technique?
3. Stretching
The hacker might do a brute force attack to crack the password.
Imagine brute forcing as trying out all number combinations on a number lock.
So they do stretching.
Think of stretching as applying the same hash function many times. Thus brute forcing becomes slower and more difficult.
A randomly generated password is always more secure. (Also keep it over 12 characters.)
It’ll slow down the hacker and make it difficult to crack the password.
Subscribe to get simplified case studies delivered straight to your inbox:
Thank you for supporting this newsletter. Consider sharing this post with your friends and get rewards. Y’all are the best.
How would you able to compare the passwords if you hash out them with the salt? hashing a one way
Amazing read Neo, easy and direct to the point. Nice visuals as well. Good job.