How Systems Store Passwords Without Keeping Them
Here is a puzzle. A well-built website can check that Olivia's password is correct, and yet it should never actually store her password anywhere. How can a system verify something it does not keep?
The answer is a technique called hashing — a one-way scramble. The site keeps a scrambled version of the password, not the password itself. And this is why a carefully built site, even when it is broken into, does not simply hand attackers everyone's passwords.
Think of a meat grinder. You can turn a steak into mince, but no one can turn the mince back into the steak. The site keeps the mince, and when a new steak shows up it grinds that one too and checks whether the two piles of mince match. From here on we will use the real term, hashing, instead of the grinder.
Why Not Just Store the Password?
The obvious design is to keep a list: each person's username next to their real password. Checking a login would then be simple — look up the row and see if the password matches.
The problem is what happens when that list leaks. A breach is when an attacker gets a copy of a system's data they were never meant to see. If the leaked data is a tidy table of real passwords, every account is exposed at once, and the attacker can log in as anyone instantly.
It gets worse. People reuse passwords across sites, so a single leaked list often unlocks accounts on other services too. A pile of real passwords is one of the most damaging things a system can possibly lose.
What Is Hashing?
Hashing means running the password through a fixed mathematical procedure, called a hash function, that turns it into a scrambled string of characters. The same password always produces the same scramble, which is what makes checking possible.
The important part is the direction. The hash function is built to be a one-way street: easy to run forwards, from password to scramble, and not reasonably possible to run backwards, from scramble to password. There is no "unscramble" button.
So the site stores the scramble and throws the real password away. If an attacker later steals the stored scrambles, they have a pile of one-way results — not the passwords that produced them.
How Does Login Work Without the Original?
This is the part that feels like a trick at first, and then feels obvious. When Olivia signs up, the site hashes her chosen password and saves only the scramble.
Later, when she logs in, she types her password again. The site hashes whatever she typed, right then, and compares the fresh scramble to the one it stored. If the two scrambles match, the password was correct.
Notice what the site never needed: her actual password, sitting in storage. It only ever compared two scrambles. The real password existed for a moment during login and was never kept.
Why "We'll Email You Your Password" Is a Red Flag
Now you can spot a badly built service from the outside. If a site can send you your actual password — not a reset link, but the real characters you chose — then it must have stored that password in a readable form somewhere.
That is exactly the thing hashing is designed to avoid. A site that hashed properly could not email your password back, because it genuinely does not have it. The most it can offer is to let you set a new one.
So "here is your password" is a sign of weak storage, while "here is a link to reset it" is the normal, healthier behavior.
- "Hashing is just another word for encryption." Encryption is reversible — with the right key, scrambled data can be turned back into the original. Hashing is deliberately one-way, with no decrypt step at all — the missing way back is the feature. (Encryption gets its own full treatment later.)
- "A breached site always leaks passwords in plain text." A site that hashed properly leaks only the scrambles, which an attacker cannot simply read back as passwords. Whether a breach is catastrophic or survivable depends heavily on how the passwords were stored.
- "If two people pick the same password, the site can see that they match." The site only stores scrambles. Well-built systems mix in extra randomness so that identical passwords do not even produce identical scrambles.
- "Throwing the password away means it can't check my login." It checks by hashing what you type at login and comparing scrambles. It never needed the stored original to confirm a match.
- It explains why some breaches are a disaster and others are survivable: the difference is whether the stolen data was real passwords or one-way scrambles.
- It gives you a simple tell for a poorly built service — one that can show you, or email you, your own existing password has stored it in readable form.
- It sets up the rest of identity: the site proves who you are without ever holding the secret you used to prove it.
Knowledge Check
Why is storing everyone's real passwords in a database considered a bad idea?
- One breach exposes every password at once
- Real passwords take up too much room to store
- A list of passwords is too slow for the site to search
- Stored passwords slowly change on their own over time
What does it mean to say a hash function is "one-way"?
- It turns a password into a scramble that cannot be reversed
- It scrambles a password but can be unscrambled with the right key
- It gives a different scramble every time, even for the same password
- It blocks people from ever typing their password into the site
How does a site check Olivia's login if it never stored her real password?
- It hashes what she typed and compares both scrambles
- It unscrambles the stored value and reads her password back
- It emails her the stored password and asks her to confirm it
- It compares her typed password to a saved readable copy
A service emails Olivia her actual existing password. What does that reveal?
- The site stored her real password in a readable form
- The site hashed her password especially carefully
- The site is offering a normal, healthy password reset
- The site forgot her password and had to guess it
You got correct