Human Brain Storage Capacity: Is It Really 2.5 Petabytes? You walk into the kitchen and stop. Whatever you came for is gone, and the refrigerator hums on no help at all. Three seconds ago the errand was fully formed. Yet catch the smell of one particular soap, the green one from a childhood bathroom, and thirty years fall away: the tile pattern, the drip of a tap, an argument murmuring through the wall. Same organ, two very different outcomes. The kitchen lapse is most likely working memory, a workspace that holds only a few chunks of information at once (about four, in many experiments) and loses them when attention moves on. The soap memory waited in long-term memory for three decades. That contrast sits awkwardly beside a figure repeated across countless web pages as the human brain storage capacity: 2.5 petabytes. A device with that much room should never misplace an errand. Either the brain is a spectacularly unreliable drive, or the number does not mean what it appear...
How Does a Website Know Your Password Is Correct Without Ever Knowing Your Password?
You type your password into a login box you've used a hundred times before your email, maybe your bank and hit enter. For a fraction of a second, nothing happens. Then the page either welcomes you back or tells you the password was wrong. That pause, barely long enough to notice, is doing something most people never stop to question. Somewhere on a server you'll never see, your password is being checked against something. But if that server is built properly, it isn't holding onto the actual word you typed, not the one you set months ago, not even a scrambled copy of it. So what, exactly, is it comparing your input to? That's the real question behind how websites verify passwords, and the answer involves one of computing's quietly elegant tricks.
The easy assumption is that somewhere there's a giant spreadsheet: your username in one column, your actual password sitting right next to it in another, and logging in is just a lookup does the box match the column? Some services genuinely have worked this way, which is precisely why, when they get breached, headlines mention lists of real passwords turning up in plain text online. But a properly designed modern system, following guidance from bodies like OWASP and NIST, never keeps a readable copy of your password once your account exists. Not because the password itself is unimportant, but because storing it in recoverable form is treated as an unnecessary risk. (Whether every website on the internet actually follows this is a separate question plenty of poorly built ones don't.)
What gets stored instead is the output of a hash function: a mathematical procedure that takes any input, however long, and turns it into a fixed-length string that bears no visible resemblance to the original. Feed it "MyPassword123" and you might get something resembling 7f9a3e21b04c8d... (a string I've invented for illustration; no real hash function would produce anything so short or so tidy). Three properties matter here. Feed the same input through the same hash function under the same conditions and you always get the same output it's consistent, not random. Change a single character of the input, even just capitalizing one letter, and the output changes completely and unpredictably; cryptographers call this the avalanche effect. And critically, there's no straightforward way to run the function backward no formula that takes the hash and hands you the password that produced it.
So here's what actually happens the instant you hit enter. Your password travels to the server over an encrypted connection (that's the padlock icon doing its job). The server doesn't compare it to a stored password, because there isn't one. Instead, it runs your freshly typed password through the same hashing procedure used back when you first set it, and lands on a result. That result gets set beside the value already sitting in the database the one produced the last time you chose that password. Match, and you're in. No match, and you're rejected.
That's the whole trick. The server never needs your actual password back only agreement between two derived values it computed the same way, twice, at different times.
There's a hole in this, though, if it's done too simply. Because hashing is deterministic, everyone who picks "password123" ends up with the identical stored hash. An attacker holding a breached database full of such hashes doesn't need to attack each one individually they can precompute the hashes for millions of common passwords just once, store the results in a giant reference table (sometimes called a rainbow table), and instantly recognize matches across every account in that database, and every other database that used the same scheme. This is exactly the shortcut salting exists to kill.
A salt is a random value, unique to each account, generated the moment a password is first set. Rather than hashing the password alone, the system hashes the password glued to its salt: password plus salt goes into the function, and what comes out is what gets stored, with the salt sitting right beside it in the same record. The salt isn't secret anyone who steals the database gets it along with everything else but it doesn't need to be secret to do its job. Two people who both choose "password123" but land different random salts end up with completely different stored hashes.
That's all salting really is. No secrecy required, just uniqueness enough to make a precomputed table worthless and force an attacker to redo the work, one account at a time. It doesn't make cracking impossible. It removes the one shortcut that made it cheap at scale.
Encryption and hashing get confused constantly, and the difference matters here. Encryption is built to be reversed: something gets scrambled using a key, and anyone holding that key can unscramble it back to the original. Password hashing is built to do the opposite job there's no key tucked away anywhere that turns a hash back into a password, because reversal was never the intention. The server isn't holding onto what you typed at all; it's holding onto a derived shape produced from what you typed, and all it can do from here is check whether some new attempt casts that same shape again.
An honest login and a break-in attempt look identical to a hash function both are just an input passing through the same procedure. The difference is scale. One person logging in triggers this computation exactly once, and a fraction of a second's delay is invisible to them. An attacker guessing passwords by brute force might try billions of candidates, and if each attempt carries even a small computational cost, that cost multiplies into something enormous at billions of repetitions. This is why modern password hashing schemes are deliberately slow, or deliberately memory-hungry, rather than as fast as the underlying hardware allows. Argon2, winner of the 2015 Password Hashing Competition, underlies OWASP's current recommended default in its Argon2id variant; bcrypt, scrypt, and PBKDF2 remain widely used alternatives, chosen depending on compatibility needs or regulatory requirements. None of these algorithms works alone each is one layer in a system that also depends on salting, sensible configuration, and how the rest of the login flow is built.
So what happens when a database of these hashes actually gets stolen, which does happen? Nowhere near as catastrophic as a plain-text leak, but not nothing either. The attacker can't simply read off passwords, but they can run an offline attack: take a list of likely passwords, hash each candidate using the correct salt and the same slow algorithm, and compare the result to what was stolen, repeating this at whatever pace their hardware allows, with no lockouts, no failed-attempt counters, nobody watching. Common and reused passwords fall to this kind of attack surprisingly fast, since attackers already have enormous lists of real passwords harvested from previous breaches to try first. A long, unique password stays out of practical reach even against unlimited offline guessing. Strong hashing and a decent password aren't substitutes for each other; the system holds up only when both are doing their part.
This also explains something people rarely connect to the rest of the picture: why "Forgot your password?" almost never emails you your old password back. If the plain version genuinely was never retained, there's nothing to send the system isn't being coy, it structurally cannot produce what it never kept. What it can do instead is verify your identity through some other channel and let you set a brand-new password, which then gets salted and hashed all over again before storage.
Strip away everything around it and a single login reduces to a short relay: your typed password meets a stored salt, the pair moves through a hashing routine tuned to be inconveniently slow, and whatever emerges gets set beside a value already waiting in the database from the day you last chose that password. They line up, or they don't. Nothing about your original password needs to exist anywhere in that chain for the comparison to work.
Which brings the whole thing back to that half-second pause after you hit enter. In that gap, no one not the server, not an administrator, not the database itself is checking your password against your password. They're checking whether two derived values, produced under the same rules, happen to agree. That a system can confirm a secret without ever holding the secret is one of the stranger ideas sitting underneath something as mundane as a login box. And it rests on ground less solid than it feels: every hash function used this way depends on the assumption that reversing it is computationally infeasible, not on any proof that reversal is actually impossible. Whether genuine one-way functions easy to compute forward, intractable to invert exist at all in the strict mathematical sense is still an open problem in theoretical computer science, tied to the unresolved question of whether P equals NP. It's known that if one-way functions exist, P cannot equal NP. Nobody has managed to prove it the other way around.
YOU MAY ALSO LIKE
Comments
Post a Comment