How passwords are stored safely
A properly built system never writes down the password you typed. Salt, deliberately slow hashing, the login check that never decrypts anything, and what a breach really does and does not hand over.
You choose a password
You pick a password and type it into a box. From this moment on, the job of every system it touches is to never write down what you actually typed. Not in a log, not in a database, not anywhere.
Sent over an encrypted link
Between your keyboard and the server it is protected by the same encryption as your banking. It exists in readable form in only two places: your fingers, and a few milliseconds of memory on the server.
Never stored as you typed it
The oldest and worst design simply stores it as typed. When one such site was breached in two thousand and nine, thirty two million passwords spilled out in plain readable text, and every account that reused those words elsewhere fell with them.
Hashed into a one way fingerprint
So the server does something one way instead. A hash function turns any input into a fixed length fingerprint with no reverse gear at all. Change one letter of the password and the fingerprint changes completely.
Fast hashing is not enough
Plain fast hashing is not enough on its own. A modern graphics card can try tens of billions of guesses a second, and prebuilt tables mean common passwords are recognised the instant they are seen.
A random salt for every account
The first fix is salt. Before hashing, the server generates a long random value unique to this one account and mixes it in, so two people who chose the same password end up with completely different stored fingerprints.
Precomputed tables become useless
That single change destroys precomputed tables. An attacker can no longer crack a million accounts in one sweep, because every single account now has to be attacked separately and entirely from scratch.
A deliberately slow algorithm
The second fix is to make hashing slow on purpose. Algorithms like bcrypt and argon two repeat the work thousands of times, and argon also eats memory deliberately, so graphics cards lose most of their advantage.
The cost factor
The tuning knob is a cost factor. Teams aim for roughly a quarter of a second per login, which no human notices, but which turns an attacker's billions of guesses a second into a few thousand.
Algorithm, cost, salt and hash
What finally lands in the database is one string holding four things: which algorithm, what cost, the salt, and the hash. It describes itself, so the system can still check passwords stored years ago under weaker settings.
Logging in: recompute and compare
When you log back in, nothing is decrypted, because nothing can be. The server pulls out your salt, runs the very same slow computation over what you just typed, and sees whether the two fingerprints match.
Constant time comparison
The comparison itself runs in constant time and never stops early at the first mismatch. A check that answered faster on a near miss would leak how much of the stored fingerprint an attacker had already matched, one byte at a time.
Quietly upgraded on the way past
Good systems also upgrade you quietly. If your stored cost factor sits below today's standard, the server rehashes with stronger settings at the one moment it legitimately has your real password in hand.
The day of the breach
Now the breach. Somebody steals the whole table. They get salts and slow hashes, so they cannot read anybody's password. They can only guess, one account at a time, at a few thousand attempts a second.
Why length beats symbols
Which is why length wins. Cracking tools work through dictionary words and predictable substitutions first, so a short password dressed up with symbols is usually guessed early. Every extra word multiplies the search instead. Hashing buys you time, and a long passphrase makes that time impossible to afford.
Watch it explain itself
Every step above is narrated aloud. Play it, or open it in the editor and make it yours — no account needed.