What a data breach actually is
A data breach means a copy of what one service had stored has ended up outside that service. The news lasts a day and the effect lasts years, because from that day on the same email and password pair gets tried against every other service.
- Lesson 8 of 12
- Beginner
- Free, no signup
The breach is news for a day and works for years
The day it is announced
A headline, a count of accounts, an apology from the company. It ends here.
-
The same pair gets tried on every other service
Automatically, and with nothing being guessed.
-
Hashes get broken again on newer hardware
A password that was expensive ten years ago is not expensive now.
-
The data is combined with other breaches
Email from one, phone from another, address from a third: a file.
-
That file becomes a targeted scam message
A message that knows your name and your order number is more believable.
This drawing is about a credential breach. A breach that leaks documents or private messages has a different shape and changing a password does not solve it.
Last checked: Facts and tool names in this lesson are re-checked against their sources on this date.
What actually comes out of a breach
The common picture of a data breach is passwords spilling out in plain readable text. That is usually not what happens, and the truth is not more comforting.
What almost always comes out is three things: the email address, the username, and a hash of the password. A hash is a meaningless looking string built from the password with no direct way back; the service does not store your password, it stores that string so it can compare next time. Alongside those three comes whatever else the service had kept: phone number, address, date of birth, order history, IP address, and sometimes the text of messages.
Having the hash means the attacker does not have your password. It means they do not have it yet. If the password is short or common, guessing a string that produces the same hash is a matter of seconds, and if the service used an old method to build its hashes, even better passwords do not hold.
And there is a second part that gets said less: the data from one breach gets combined with the data from others. Email from one, phone number from another, address from a third. None of them matters on its own and together they are a file, and it is that file which turns a scam message from generic text into a message that knows your name and your order number.
Why a password leaked three years ago is still dangerous
A breach does not end when it is published. That is when it starts, and what comes afterwards never makes the news.
The main thing done with that data has a name: credential stuffing. The email and password pairs are taken and tried automatically against dozens of other services. Nothing is guessed and no vulnerability is needed; if you used the same password somewhere else, that account opens too. Notice that the second service did nothing wrong. The bridge connecting the two is password reuse and nothing else.
The second thing is slower and just as real: hashes get broken again as time passes. Hardware gets cheaper and faster every year, so a password that was expensive to crack in 2015 is not expensive now. Which means the data from an old breach becomes more valuable over time, not less.
And the third is what the previous section described: data gets combined and turned into targeted phishing. A message that knows which shop you bought from and how much you paid beats any generic warning about scams.
So the right question after hearing about a breach is not how badly that company behaved. It is where else that same password lives.
How to find out your password leaked, without sending it anywhere
There is a service called Have I Been Pwned that has collected a body of leaked data and lets you ask whether your email or your password is in it. Any sane person reacts to the second half of that by pointing out that typing your password into a website to find out whether it leaked is insane. That is entirely correct, and it is not what happens.
Here is how it works. The password is turned into a hash on your own device; nothing has left your computer yet. Then only the first five characters of that hash are sent. The service replies with every leaked hash that begins with those five characters, and the final match is made on your own machine.
On 7 September 2026 we ran exactly that. For one of the most common passwords in the world, the service returned 1,978 rows. Which means even someone watching that request only knows the password in question is one of those 1,978 and not which one; the password itself never left the device.
And the answer that came back for it is a number worth looking at. The string password has been seen 52,372,427 times in the leaked password set. The string 123456 has been seen 210,461,208 times. These are not counts of people, they are counts of how often that password appears across the collected breaches, and that is enough to understand one thing: every guessing list an attacker uses starts here.
One note about a negative answer. If a password is not found, that means it is not in the data this service holds. It does not mean the password is a good one, and it does not mean it never leaked; a breach that has not become public yet is on no list at all.
How a password gets checked without being sent
-
1
The password becomes a hash on your own device
Up to here nothing has left your computer.
-
2
Only the first five characters of that hash are sent
Five characters cannot be turned back into a password.
-
3
The service returns every leaked hash with that prefix
In our test 1,978 rows came back.
-
4
The match is made on your own machine
The service never learns which of those rows was yours.
This method says whether the password is in the data this service holds. Absence means it is not in that data, not that it is a good password.
What to do after a breach, in this order
Most people react by changing the password on the service that was breached. That is necessary and it is not sufficient, and more to the point it is the easiest step, so it is usually the only step anybody takes.
The order that actually works has four steps.
Step one is that: change the password on the breached service. Step two is the real work and takes the most time: change it everywhere else you used the same password or a close relative of it. This is where one account becomes ten accounts and this is where most people get tired and stop.
Step three is two factor authentication, and it starts with the email account rather than the bank account. The reason is that email is the master key: the forgot my password button on every other service delivers to that same mailbox, so whoever has your email recovers the rest without ever needing to know their passwords.
Step four is patience. For a few weeks, watch for messages that open with correct information and then ask for something; exactly what the first section described combined data producing.
And one thing not to do, because it is common and useless: changing the password to a variation of the same password. A password with one more digit on the end builds no protection against the same list of the same pairs; those lists try that pattern too.
Four steps after a breach, in this order
-
1
Change the password on that service
Necessary, and the easiest step.
-
2
Everywhere else that password lived
This is the real work and it takes the most time.
-
3
Two factor, on the email account first
The forgot password button of every other service delivers to that mailbox.
-
4
Watch for odd messages for a few weeks
A message that opens with correct information and then asks for something.
This order is for a credential breach. If a card number or an identity document was also in the leak, the bank and the issuing authority have steps of their own and these four do not stand in for them.
Why a unique password turns a disaster into a nuisance
Everything above arrives at one conclusion, and the conclusion is one sentence: if the password for each service belongs only to that service, a breach of that service opens exactly one account and your work is one password change. If passwords are reused, the same breach opens as many accounts as held that password.
The difference between those two situations is the difference between ten minutes and ten days, and it has nothing to do with how strong the password was. A very strong password reused across three services performs worse, when one of those three leaks, than a weak unique one.
And now the position, because this is where people get stuck: yes, keeping unique passwords without a password manager is not realistically possible, and yes, a password manager means all the eggs in one basket. That objection is real and we are not dismissing it. But look at the whole trade: the other side of it is password reuse, which also means all the eggs in one basket, except that any of ten different companies can break it. An encrypted vault that opens with one master password and a second factor is the safer place, and we say that as a position rather than as a neutral fact.
The next stage of this argument is building a password worth making unique and turning on that second factor; both are covered in other lessons of the security track.
And if you run a site, this lesson has another half. A data breach is not only something that happens to other services; your own database holds the same rows of emails and hashes and is worth exactly as much. Hardening that side of it is what we do under website security.
The fast path, with AI
The fast path here is not asking a model whether your data leaked; it does not know and it will guess. It is doing the check yourself in one line, and using the model only for the part that is genuinely work: turning a list of breached services into an order of work. What separates this from the ordinary way is that the ordinary way gets abandoned after the third account, and having an order is exactly what stops the abandoning.
- Check your email address on the breach service and take the list of services whose breaches you were in.
- Check the passwords with the prefix method rather than by typing them into a page. One line of command does it and the password never leaves the device.
- Give the model the list of service names, never the passwords, and ask it to rank them by what each account further unlocks.
- Do the top three today. The rest can wait, and if you start all of them today none of them finishes.
Copy-ready recipe
Checking a password without sending it, on Linux or Mac. The password is typed but not shown, and is cleared from memory at the end:
read -rs P; H=$(printf %s "$P" | sha1sum | cut -c1-40 | tr a-f A-F); curl -s "https://api.pwnedpasswords.com/range/${H:0:5}" | grep -i "^${H:5}"; unset P H
If a line comes back, the number after the colon is how often that password
has been seen in leaked data. If nothing comes back, it is not in this set.
The prompt, with the list of service names pasted underneath. You send no
passwords:
These are the names of services whose data breaches my email address was in.
Rank them by what else opens up for someone who reaches that account, rather
than by how large the breach was. For each one write:
a) if the same password was used elsewhere, which accounts are at risk
b) whether this service offers two factor authentication, and of what kind
Always put the email account at the top of the list, even if it is not in the
breach list. Mark any service you do not recognise as unclear rather than
dropping it from the list.Before you trust the output: Three boundaries whose crossing spoils the whole thing. Do not give the passwords to the model under any circumstances; the service names are enough and the model has no use for a password. Do not paste the full breach list with dates and personal fields; the names alone are enough. And the order the model produces is a priority, not a verdict: a service the model does not recognise still needs its password changed, and if the model states a date or a size for a breach, check it against the breach service itself; that is precisely the class of fact models misremember.
AI in this kind of work
On this topic a language model has one useful job and one dangerous one, and the distance between them is shorter than in any other lesson. The useful job is ranking: from a list of twenty services, saying which come first. The dangerous one is letting it see the sensitive data, and here the sensitive data is the very thing the whole subject is about.
Tools that actually help
- Have I Been Pwned Not an AI tool, and deliberately at the top of the list. The real data lives here, and no model knows which breaches you were in; if it says, it made it up.
- Claude For ranking the list of services by what each one further unlocks; it writes out its reasoning and you can disagree with it. Iran is on neither of Anthropic two supported-countries lists and there is no official payment route from Iran.
- Gemini For volume work: reading several breach descriptions in a row and pulling out which fields each one exposed. Google own page says the Gemini web app runs in over 230 countries and territories, and Iran is not on that list.
- RGB The access and payment layer for Iran, kept separate from the tools themselves.
Where it backfires
One rule here has no exceptions: never type a password into a chatbot, for any reason, including is this password strong. Your conversation is stored on most plans, depending on plan and settings it may also feed model training, and anyone who later gains access to that account can read it; you have turned your password from a secret into a row in a history. The question is this password strong can be asked without the password: describe its shape, how many words it is and whether it is reused anywhere. The second risk is narrower and belongs to this lesson specifically: models speak confidently about which company was breached in which year, and breach dates and sizes are exactly the class of fact they misremember. Ask the breach service itself. Each service also writes down its own storage and training policy, including on Google privacy page for the Gemini apps.
Sources: Have I Been Pwned: Pwned Passwords Have I Been Pwned: API v3 documentation Google: Gemini Apps privacy Anthropic supported countries
Where this advice stops
A breach checking service only knows what has been given to it. An answer of not found means it is not in that collection, not that you are safe; a breach that has not been discovered or disclosed yet is on no list at all, and years sometimes pass between a breach happening and becoming public. The second boundary is the subject: this lesson is written about credential breaches. A breach that leaks documents, private messages, photographs or identity papers is a different kind of thing and changing a password does not make up for it, because that data cannot be taken back. And the third boundary said plainly, because the wrong kind of hope grows here: nothing in this lesson brings back data that is already out. All that can be done is to stop that data connecting to your other accounts.
From our own work
The prefix method described in this lesson was run on 7 September 2026 and its numbers are quoted from that run. For the string password, the first five characters of the hash were sent and the service returned 1,978 rows; the row for that password said it had been seen 52,372,427 times in leaked data. We repeated it with 123456: 1,921 rows came back and its number was 210,461,208. The one line command in the fast path section is the command that was run, and it produced that output.
What we found interesting in that run was the row count. 1,978 is not a large number and you expect a larger one, but it is already enough that whoever sees the request cannot say which row is yours. Which means the privacy of this method does not come from clever cryptography; it comes from a simple choice about prefix length. And that is exactly why it is reproducible: anybody can run the same line and see the same thing.
Real follow-up questions
My email was in a breach list but nothing has happened; do I need to do anything?
Yes, and precisely because nothing has happened yet. Leaked data has no expiry date, and trying that pair against other services can happen two years after it was published. If the password belonged only to that one service, your work is one password change and it is over.
Is it safe to enter my password on a breach checking site?
The prefix method described in this lesson does not send the password, and in that sense it is safe. But if you would rather not have to trust anyone, run the one line command on your own computer; it does the same thing with no page in between. The general rule is this: anywhere that asks for your full password in order to tell you whether it leaked is not using the right method.
Should I change my email address?
Usually no, and that question is asked more out of despair than out of security. An email address is meant to be public; what is not meant to be public is the password. Changing your email costs a lot, every service has to be set up again, and the old data that is already out stays where it is. Spend that same time turning on two factor authentication on that email instead; it does more.