Password Management

You Can't Un-bake a Cake

Imagine you have a recipe for an incredible chocolate cake. You mix flour, sugar, cocoa powder, and eggs, put the batter in the oven, and bake it.

If someone breaks into your kitchen and steals the baked cake, they have a delicious dessert. But no matter how hard they try, they cannot reverse the chemical process to extract the raw eggs out of the baked cake. The baking process is a one-way street.

When we build authentication systems for our applications, we must treat user passwords exactly like raw ingredients. We never store the raw password. We "bake" it into an irreversible string of characters.

If a hacker breaks into our database and steals the data, we want them to find a bunch of useless, un-reversible cakes, not the raw passwords. This process is the cornerstone of Password Management in system design.

The Catastrophe of Plain Text

In the early days of the internet, companies stored user passwords in their databases in "plain text." If your password was hunter2, the database column literally contained the string hunter2.

This is a catastrophic security failure. If an attacker dumps the database, they instantly compromise every user. Even worse, because users notoriously reuse the same password across multiple sites, a breach on an obscure forum could hand hackers the keys to the users' email and banking accounts.

Hashing: The One-Way Function

To solve this, we use cryptographic Hashing.

A hash function (like SHA-256) takes an input of any size and scrambles it into a fixed-length string of characters. For example, hashing the word apple might produce 3a7bd3e2...

Crucially, good hash functions are one-way. You cannot run a mathematical function to turn 3a7bd3e2... back into apple.

So, when a user creates an account:

1. They type hunter2.
2. The server hashes hunter2 into 8b1a9953...
3. The server saves 8b1a9953... in the database. The raw password is discarded.

When the user logs in tomorrow:

1. They type hunter2.
2. The server hashes it again to 8b1a9953...
3. The server compares the new hash to the hash in the database. If they match, the password was correct!

The Threat of Rainbow Tables

Hackers are smart. They realized that since hashing functions always produce the same output for the same input, they could just pre-compute the hashes for every word in the dictionary and every common password.

They built massive lookup tables, called Rainbow Tables.

• password123 = cbfa...
• qwerty = d857...

If they steal your database, they just compare your hashes against their Rainbow Table. If they find a match, they know the original password instantly.

Salting: Spoiling the Rainbow

To defeat Rainbow Tables, we use a technique called Salting.

A salt is a random string of characters generated for every single user when they sign up. Instead of hashing just the password (hunter2), we combine the password with the random salt (hunter2 + XyZ98) and hash that combination.

We then store both the salt and the resulting hash in the database.

Because the salt is random and unique to each user, a hacker's pre-computed Rainbow Table is completely useless. Two users could both have the password hunter2, but because they have different salts, their hashes in the database will look entirely different. The hacker would have to generate a custom Rainbow Table for every individual user, making the computational cost practically impossible.

Key Derivation Functions (Slow Hashing)

Computers keep getting faster. Today, a standard GPU can calculate billions of simple hashes (like MD5 or SHA-256) per second. A hacker could try to brute-force a salted password by guessing millions of combinations rapidly.

To counter this, modern password management uses Key Derivation Functions (like bcrypt, Argon2, or PBKDF2).

These algorithms are intentionally designed to be slow and computationally expensive. They might take 100 milliseconds to calculate a single hash.

For a normal user logging in, waiting 100 milliseconds is unnoticeable. But for a hacker trying to calculate 10 billion guesses, that 100-millisecond delay turns an attack that would have taken hours into one that takes decades.

Summary

• Never store passwords in plain text. If your database is compromised, the damage is infinite.
• Use Hashing to turn passwords into irreversible strings. You can verify a login by hashing the attempt and comparing the outputs.
• Add a unique, random Salt to every user's password before hashing it. This completely defeats pre-computed attacks like Rainbow Tables.
• Use slow hashing algorithms (bcrypt, Argon2, PBKDF2) to make brute-force guessing computationally infeasible for attackers.