You're previewing the Bennett demo family. Numbers, schedule, and kids are sample data.Start your own
Loading page…
A well-built website does not know your password. It has never known it. It cannot tell you what it is, cannot look it up, and cannot be persuaded — and it still recognises you every single time you type it.
You make an account. You choose a password. You come back next week, type the same password, and you are let in.
Almost everybody's mental picture of that is a list. Somewhere on a computer there is a column of names and a column of passwords, and the site walks down it looking for the row that matches.
That picture is wrong, and it is worth noticing how bad an idea it would be. It would mean every employee who could reach that list could read your password. It would mean anybody who stole the list could walk into your email, and then everything attached to your email. And it would mean the site could tell you your own password if you asked nicely — which some of them, alarmingly, do.
A well-built site does not store your password. It stores something made FROM your password, which cannot be turned back into it.
Some jobs are easy forwards and effectively impossible backwards. Stirring milk into tea takes a second; separating them again is not a harder version of the same job, it is a different and hopeless one.
Computers have a mathematical version of that, and it is called a hash. You feed it any text at all and it gives back a fixed-length jumble of characters. Three properties make it useful:
So the site stores the jumble. When you come back and type your password, the site hashes what you just typed and compares the two jumbles. Same jumble means same password. It got its answer without ever holding the secret.
Follow a real account, one step at a time. The password is `hello`, which is a genuinely terrible password and is being used here only so you can check the jumbles yourself — these are real outputs of a hash called SHA-256, not invented ones.
You click 'forgot password' on a site, and it emails you the password you chose two years ago. What have you just learned about that site?
You can judge a lot about a company's care from the outside, using only what you now know about how storage works. Sort each behaviour and read the reasoning.
Tap an item, then tap where it belongs
There is a hole in the plan as described, and it comes from the very property that makes it work: the same text always produces the same jumble.
So if ten thousand people on a site all chose the same weak password, all ten thousand rows in the stolen database look identical. A thief does not need to break anything. They hash the ten thousand most common passwords once, in advance, and then simply look for matches — one afternoon's work, and it unlocks every one of those accounts at the same time.
The fix is called a salt. When you sign up, the site generates a short random string just for you, sticks it on the front of your password, and hashes the pair together. It stores the salt beside the jumble, in plain view — the salt was never a secret.
Now two people with the identical password store completely different jumbles, because they were never hashing the same text. The thief's pre-made list is worthless, and every single account has to be attacked separately, from scratch.
A salt does not make one password harder to guess. It makes guessing them all at once impossible, which is the attack that actually happens.
Two people on a salted site happen to choose exactly the same password. Their stored jumbles look nothing alike. Why not?
You’re previewing as a parent — nothing here is recorded.
The two hashes shown are real SHA-256 outputs, computed and verified rather than quoted from memory. SHA-256 of 'hello' is 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824; SHA-256 of 'Hello' is 185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969. Anyone can reproduce both with a standard library. The episode shows the first eight and last eight characters of each. SHA-256 always produces 256 bits, written as 64 hexadecimal characters, regardless of how long the input is — which is why a hashing site has no technical reason to impose a short maximum password length. The 'one character changes everything' property is called the avalanche effect and is a deliberate design requirement of cryptographic hash functions, not an accident; the two hashes above are a direct demonstration of it. Salting: storing a unique random value per user and hashing it together with the password is standard practice (NIST Special Publication 800-63B recommends salting and the use of a slow, memory-hard password hashing function). The salt is stored alongside the hash and is not secret; its purpose is to defeat precomputed lookup tables and to stop one cracking effort from covering many accounts at once. Real cases of both failures are documented. LinkedIn's 2012 breach exposed password hashes that were unsalted SHA-1, which allowed large numbers of them to be recovered quickly by guessing; the incident later proved to affect over 100 million accounts. Adobe's 2013 breach of around 153 million records was worse in kind: the passwords had been reversibly encrypted rather than hashed, and stored password hints were included, making large-scale recovery of the actual passwords possible.