What happens to your password after a breach
Follow one password from a leaked database to somebody else's account being taken over. The mechanics explain why reuse is the only fact that matters.
What is actually in the dump
A breach dump is a copy of rows out of a database. Usually one table, sometimes a whole export. It is not somebody sitting inside your computer, and it is not live access to your account. It is a text file that gets traded, merged with other text files, and eventually posted for free.
A row looks roughly like this:
id email password_hash signup_ip created
81237 ali@example.com $2y$10$N9qo8uLOickgX2ZMRZo4i.O... 41.33.14.207 2019-03-11
81238 sara@example.com 5f4dcc3b5aa765d61d8327deb882cf99 197.44.9.18 2019-03-11
Alongside that you often get: username, phone number, date of birth, address, the answers to security questions, and every IP you ever logged in from. What you usually do not get: full payment card numbers, because those normally live with the payment processor, and the contents of your account, because messages and files are not in the users table.
Two things in that list matter more than people expect. Security question answers are permanent — your mother's maiden name does not rotate. And phone numbers are what make SIM-swap attacks targeted rather than opportunistic.
Plaintext, encrypted, hashed
The password field is one of three things.
Plaintext. The password, readable. Still happens.
Encrypted. Reversible by design. There is a key, the application needs that key to work, and the key usually lives on or near the machine that was already taken. In 2013 Adobe lost around 150 million records encrypted with 3DES in ECB mode — meaning identical passwords produced identical ciphertext — and shipped the password hints in plaintext in the same dump. People solved it like a crossword. Encryption of passwords is not a security control; it is a delay.
Hashed. A one-way function. password goes in, 5f4dcc3b... comes out, and there is no inverse function. This is the only correct answer.
Why a hashed password is still often recoverable
Because nobody tries to reverse it. They guess.
The attacker takes a candidate, hashes it, and compares. If it matches, that was the password. The entire game is: how many guesses per second, and how many guesses are needed.
Guesses per second is a property of the hash. MD5, SHA-1 and SHA-256 were built to be fast — they are meant for checking file integrity at line rate. On a hash designed for speed, one high-end consumer GPU does tens to hundreds of billions of attempts per second. bcrypt and Argon2 were built to be slow on purpose. bcrypt has a cost factor you increase as hardware improves. Argon2 and scrypt go further and are memory-hard: each guess needs a large block of memory, so the bottleneck becomes memory bandwidth rather than arithmetic, which is exactly where GPUs and custom silicon lose their advantage.
The ratios, for one high-end consumer GPU, as orders of magnitude:
| Stored as | Guesses per second | One trillion candidates takes | | --- | --- | --- | | MD5 / SHA-1 | ~10¹¹ | ten seconds | | SHA-256 | ~10¹⁰ | two minutes | | bcrypt, cost 12 | ~10³ | decades | | Argon2id, tuned | ~10² – 10³ | decades |
Hardware moves. The ratios do not.
The second half is the number of guesses needed, and this is where people misjudge their own passwords badly. Candidates are not random. They come from every previous breach, concatenated and sorted by frequency, then mutated by rules — capitalise the first letter, append a digit, append a year, swap a for @, swap o for 0. A standard run is one command:
hashcat -m 0 hashes.txt rockyou.txt -r rules/best64.rule
That applies 77 mutations to fourteen million known passwords. So:
password → Password → Password1 → P@ssw0rd1 → P@ssw0rd2019!
P@ssw0rd2019! looks strong to a strength meter. It is four rules away from one of the most common passwords on earth, and it falls in the first minute.
Salting is the other thing worth understanding, because it is routinely oversold. A salt is a random value stored next to the hash. It means two users with the same password get different hashes, so precomputed tables are useless and one cracked hash covers one account instead of thousands. What a salt does not do is slow down guessing against your hash. Only a slow hash does that.
Cracking is not reversal. It is guessing at scale. Every real defence either raises the price of one guess or raises the number of guesses needed — nothing else.
The practical effect of bcrypt or Argon2 is economic. An attacker with a million hashes and a fixed GPU budget cracks the cheap ones and abandons the rest. With MD5 they get almost everybody. With Argon2 they get the people who used 123456, and you are simply not worth the electricity — unless someone is specifically after you.
Then it becomes a line in a combo list
Whatever cracks gets written as email:password and merged into a combo list spanning hundreds of breaches. This is the input to credential stuffing: take the pair, try it against banks, email providers, retailers, airlines, cloud consoles.
This is the whole mechanism, and it is why one fact dominates everything else. The forum that lost your password in 2019 does not matter. Your email provider's cryptography does not matter. If the password is the same, the attacker does not attack anything — they log in.
The tooling is mature and boring: stuffing frameworks with per-site "configs" that know each login endpoint and how to recognise success, residential proxy pools that spread attempts across tens of thousands of home IP addresses, and CAPTCHA-solving services priced per thousand. Success rates per attempt are a fraction of a percent. It does not need to be better than that. The marginal cost of one login attempt is close to zero, and the list has ten million rows.
Rate limiting and lockout, from the attacker's side
Defenders reason vertically: too many failures on one account, lock the account. Attackers do not attack vertically.
With a combo list you have one password per account, so you make one attempt per account across a million accounts. Every per-account counter stays at 1. Nothing locks. Per-IP limits are answered by rotating through the proxy pool, one attempt per address, from IP space that looks exactly like customers. Velocity limits are answered by slowing down; a job that finishes in a week is fine.
Lockout has a second problem: it is a weapon. If ten failures locks an account, anyone who knows your email can lock you out of your own bank whenever they like. That is why serious providers stopped counting failures and started scoring risk — device history, ASN reputation, geography that is physically impossible, typing that does not look human — and respond by demanding another factor rather than blocking.
Here is what rate limiting genuinely achieves, and it is not small: it makes online guessing of an unknown password hopeless. A few attempts per account per hour against a decent password is never going to land. That is precisely why the real routes are offline cracking of stolen hashes and reuse of known-good passwords. Rate limiting did not fail. It pushed the attack somewhere it works, which is your other accounts.
What the takeover looks like
Say a stuffed password lands on your email. The sequence is fast and it is not what people imagine.
First, persistence that survives a password change: a mail forwarding rule, or an OAuth grant to an innocuous-looking "calendar sync" app. Changing your password does not revoke either.
Then harvesting, by search:
subject:(invoice OR "wire" OR "bank details") has:attachment
"reset your password" OR "verification code"
Then pivoting. Your email is the master key, because every other account resets through it. This is why email is the account to defend first, and why "it's just my email" is the most expensive misunderstanding in this article.
Password managers, including the honest part
The distrust is rational. One vault is one target, and in 2022 LastPass had encrypted customer vaults stolen. What protected people afterwards was a long master passphrase and modern iteration settings; old accounts on legacy settings had a much worse time, and some metadata — including site URLs — was not encrypted at all.
I still use one, and so should you, for a reason that has nothing to do with trusting the vendor. A manager converts a problem you cannot solve — remember two hundred unique strings — into one you can. It eliminates reuse, and reuse is the single input credential stuffing requires. Trading a low-probability vault compromise for the certainty of not being in tomorrow's combo list is a good trade.
There is a second benefit nobody advertises: autofill is domain-bound. On paypa1.com your manager offers nothing, and that silence is a better phishing detector than your judgement at 7am.
Long random password per site, generated by the tool. A passphrase for the master. Second factor on the vault itself.
What 2FA stops, and what it does not
| Attack | Second factor helps? | | --- | --- | | Credential stuffing, offline cracking | Yes. Completely. The password alone is now useless. | | Real-time phishing proxy | No. The fake page relays your code and steals the resulting session cookie. | | SMS interception, SIM swap | No, if the factor is SMS. | | Push-approval fatigue | Barely. People tap approve at 3am. | | Malware stealing session tokens | No. It bypasses login entirely. | | Support-desk social engineering | No. That is the recovery flow, not the login. |
That first row is the one that matters, and it is why 2FA is worth the friction. SMS is the weakest form and still far better than nothing. An authenticator app is better. A hardware key or a passkey is better again, because those two are the only ones that survive real-time phishing.
Passkeys, plainly
Your device generates a key pair for one site. The public key goes to the site; the private key never leaves your device or your encrypted platform keychain, and it is unlocked by your fingerprint, face or device PIN. To log in, the site sends a random challenge and your device signs it.
Two consequences, both mechanical.
The site never holds a secret that logging in requires. Breach the database and you get public keys, which are useless — there is nothing to crack, so the whole first half of this article stops applying.
And the signature is bound to the origin by the browser. A passkey registered for bank.com will not sign for bank-secure-login.com, regardless of how convincing the page is or how tired you are. Phishing and stuffing die together.
The honest limits: recovery is the soft spot, and if you lose every device you fall back to email or SMS — the old weak path. Synced passkeys are only as safe as the platform account holding them. And coverage is still patchy, so you will be running passkeys and passwords side by side for years.
If you learn you were in a breach
In this order, because the order is the whole point.
- Email first. New unique password. Everything else resets through it.
- Revoke, don't just change. Sign out all sessions, then review connected apps and OAuth grants, mail forwarding rules, and the recovery email and phone. A changed password does not remove a forwarding rule an attacker added.
- Second factor on email, then money, then the rest. Add a passkey wherever it is offered.
- Find every place you reused that password. This is the actual work. The breached site is the least of it.
- Treat leaked security answers as public forever. Replace them with random strings kept in your manager. They are just passwords with a worse name.
- Replace a leaked card instead of monitoring it.
- Check haveibeenpwned.com, and ignore anyone selling removal of your data from dumps. A file that has been copied ten thousand times cannot be recalled.
Closing
You do not get a say in how the companies holding your data store it. You will not know whether they chose Argon2 or MD5 until the day it leaks, and you will usually find out months after everyone else did. That part is genuinely outside your control, and I am not going to pretend otherwise.
What you control is whether one leaked row is worth anything to the person holding it. Unique passwords make it worth one account. A second factor makes it worth nothing. That is the entire lever, and it is shorter than most of the advice written about it.