Data Breach Check: Are Your Details Already Out There?
A data breach check without handing over your password: how k-anonymity works, where to test an email address, and what a hit actually tells you.
A data breach check is mostly an exercise for people who did nothing wrong. Some shop you ordered from six years ago got broken into, the customer database ended up in the usual forums, and ever since your address has been sitting in lists that get copied, traded and worked through by software. You rarely find out. Disclosure duties apply when the provider notices the incident at all and knows who was affected, and both happen less often than they should.
There is a way to look instead of guess. You examine yourself the way an attacker would: which of my details are already circulating? That change of viewpoint is the whole idea behind defensive reconnaissance, and it needs neither specialist knowledge nor anything you have to pay for. Twenty minutes and two websites get you a solid picture.
The tricky part is the password lookup, for a good reason. A form asking for your password looks exactly like a phishing page. Why one of them is harmless and the other is not comes down to a mechanism with an awkward name, and that is the most interesting section further down.
What a breach actually is
A breach happens when a provider loses the customer data it holds. The usual routes are a vulnerability in a web shop, a misconfigured server, or a staff account somebody took over. What flows out is rarely spectacular: email addresses, names, passwords or their hashes, often postal addresses and phone numbers, sometimes dates of birth or order histories.
The interesting part is what happens next. The records get cleaned up, merged into large collections and then reused automatically. The term for it is credential stuffing: a program takes the address and password pair and tries it against hundreds of other services. Nothing is guessed, it is looked up. A one percent success rate is plenty when you have millions of records.
That is where the central insight of this whole subject sits. The bike shop breach is harmless in itself, as long as the password used there was used only there. It becomes a problem when the same pair opens your inbox, and an inbox opens nearly every other account through password resets. The chain does not start with the attacker. It starts with the convenience of one memorable password used in several places.
Something else that rarely gets said plainly: old breaches barely age. An address stays the same for years, and a password that leaked in 2019 and was never changed still works today. That is why current collections routinely contain records a decade old.
Checking an email address
Start with the email address, because it appears in almost every breach and because, unlike a password, you can safely type it anywhere. Two services are established here and they complement each other rather than overlap.
Have I Been Pwned (haveibeenpwned.com) has been run since 2013 by the Australian security researcher Troy Hunt. You enter your address and immediately see, on the page, the list of publicly known incidents it appears in, each with the provider, the date and which categories of data were involved. That last column is the useful one. An incident where only addresses leaked calls for a different response than one that included passwords. There is one exception: incidents classified as sensitive, the Ashley Madison breach among them, are only shown after you confirm the address by email.
The Identity Leak Checker run by the Hasso Plattner Institute (sec.hpi.de/ilc) is the German counterpart and worth knowing even outside Germany, because it answers a broader question. The institute in Potsdam has been collecting leaked and publicly accessible datasets since 2014, dark web sources included, and checks which identity attributes circulate alongside an address: name, postal address, date of birth, phone number, password. The result is only released after a confirmation: the institute emails a one-time password to the address you entered, and once you type that in, the result appears on the page.
That extra step looks clumsy and is precisely why the service can be trusted with more data. Because the result is unlocked only through the inbox being tested, nobody can run other people’s addresses through it to assemble a target list. The difference to Have I Been Pwned is smaller than it first appears: both tie the result to control of the inbox, the institute always, Have I Been Pwned for the incidents it classifies as sensitive. The institute is attached to the University of Potsdam, has been collecting breach data since 2014 and offers this lookup free of charge, with no subscription page at the end of it.
The password check that does not reveal your password
Now the core of it. Alongside the address search there is the Pwned Passwords database, which answers a different question: does this particular string appear in known breaches? On first contact that feels wrong. Every sensible guide tells you never to type your password anywhere, and here you are asked to do it on a security site of all places.
The contradiction dissolves the moment you look at what actually travels over the wire. The mechanism is called k-anonymity and it runs in four steps.
One. Your browser computes a SHA-1 hash of the password locally, a
fixed-length checksum. The function itself cannot be reversed, but for a common
password the matching hash has long been known and can simply be looked up. The
safety of this lookup therefore does not come from the hashing, it comes from the
steps that follow. The word password always and everywhere produces the same
string: 5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8.
Two. Only the first five characters of that hash are cut off and sent to the
API, in this example 5BAA6. Nothing else leaves the device. Not the password,
not the full hash.
Three. The server replies with every hash ending it holds for that prefix, typically around two thousand entries, each with a count of how often it has appeared in breaches.
Four. Your browser compares that list against the full hash it kept the whole time. The matching happens locally, on your machine.
The consequence of that construction: the server sees five characters that match around two thousand hashes in its own dataset alone, and never learns which password you checked. It cannot even tell whether you got a hit, because the response is identical for everyone querying the same prefix. Cloudflare, which serves the lookup, described the model in detail back in 2018, and the same mechanic now sits inside the breach warnings of many browsers and password managers.
This is exactly where the line runs between a tool and a trap. A serious service explains the mechanism, and you can verify it if you want to, because the API is openly documented. A random web form that asks for your password and says nothing about any of this is a password collection with a friendly face. The rule is inconvenient and short: if it does not say that only a hash fragment is transmitted, you type nothing.
You got a hit. Now what?
Nothing hasty. A find in a password database concerns a character string first
of all. Your account is not in there. If your password is Summer2019! and the
database knows it ten thousand times over, that only means plenty of other people had the same
obvious idea. Nobody was in your inbox.
Act anyway, because a known string sits in the wordlists automated attacks run from, which makes it worthless. The order:
- Change the password where it does the most damage first. Email inbox, then banking, cloud storage, Apple or Google account, then social accounts. Every account gets its own string.
- Be honest about where else you used it. This step is the tedious one and
the one that counts, because credential stuffing lives on it. Variants count
too: turning
Summer2019!intoSummer2020!gains nothing, since those derivations are built into the attackers’ rule sets. - Turn on a second factor wherever it exists. An authenticator app or a hardware key beats SMS, because a SIM swap defeats the SMS route. A stolen password on its own then buys nothing, and this is the single most effective item on the list.
- Set up a password manager. It is the reason steps one and two take five minutes next time. Many of them check their stored entries against the same breach data continuously and speak up on their own.
- Look at the affected service. Active sessions you do not recognise, an unfamiliar recovery address, forwarding rules you never created.
If at this point you suspect it did not stop at the breach, with logins from countries you have never visited or verification codes arriving without you trying to sign in, that is a separate subject with its own sequence. We wrote it up separately: am I hacked sorts the signs that actually prove something from the ones that merely look alarming.
What a data breach check cannot do
This part is uncomfortable and belongs in any honest treatment of the topic. A breach checker finds what is in its database, and nothing else. Whatever never became public, whatever is traded in closed circles, whatever happened last week, is missing.
A clean result therefore does not mean “safe”, it means “not present in this dataset”. The difference has practical consequences, because a clean result tempts people to skip everything else. Three further limits belong with it:
- A password hit measures how widespread a string is. Nothing about the state of your account follows from it. The common numeric sequences are leaked millions of times over, which concerns everyone who uses them and nobody personally.
- Breached data does not go away. No service can pull records back out of circulation. What leaked stays copyable, and the only real lever is to lower the value of those copies by rotating passwords and putting a second factor in front.
- A check is a snapshot. Tomorrow a dataset may surface that involves you. This is why an automatic notification on new findings is worth more than a one-off lookup.
Quick comparison
| Check | Question answered | What leaves your device | Result |
|---|---|---|---|
| Have I Been Pwned, address search | Which known breaches contain my address? | the address | instantly on the page, sensitive breaches after confirmation |
| Pwned Passwords | Does this string appear in breaches? | five characters of a hash | instantly, matched locally |
| HPI Identity Leak Checker | Which identity data circulates with my address? | the address | on the page, after email confirmation |
| Breach alerts in a password manager | Are stored logins affected? | hash fragments | continuously, inside the app |
What is left
For most people the question “have my details leaked” has the same answer, and it is yes. With several hundred incidents in the publicly documented collections alone, a ten-year-old email address with no hits is the exception. That sounds worse than it is, because the number that matters is not the breach itself but what it still unlocks.
And that part is entirely within reach. A unique password per service confines any future incident to that one service, and a second factor renders a stolen password useless on its own. Both are unglamorous, cost nothing, and work more reliably than any subscription with dark web monitoring in the name.
The rest is a habit: look your own addresses up twice a year instead of hoping nothing has happened. If you want the same view of the wider shadow you cast, our piece on what Google knows about you covers the profile side of it, and the question of who actually controls your identity online sits in digital identity. Looking is the cheaper form of security in all of these cases.
Frequently asked questions
- Is Have I Been Pwned legitimate?
- It has been run since 2013 by the Australian security researcher Troy Hunt and indexes breaches that have already become public. The security industry treats it as a reference and the lookup is free. What matters more than the reputation is the construction: for the password lookup, the design makes it impossible for the server to learn which password you typed. That property can be read up on and checked, so it does not require trust in anyone.
- Is it dangerous to type my password into it?
- Not for the Pwned Passwords lookup, because the password never leaves your device. Your browser computes a SHA-1 hash locally and sends only the first five characters of it. The service returns every hash ending that starts with those five characters, and the comparison happens back in the browser. Any other form that asks for a password and does not explain this mechanism deserves the opposite treatment: do not type anything in.
- My password was found. Does that mean I am hacked?
- No. The password database tells you that this character string appears somewhere in a known breach, not that your account was touched. A common password shows up millions of times even though nobody has ever been near your inbox. In practice it changes little: a string sitting in attacker wordlists gets tried automatically, which makes it spent. Replace it everywhere you used it.
- What is credential stuffing?
- The automated reuse of leaked logins. Attackers take an email and password pair from one breach and run it against hundreds of other services, from shops to streaming to cloud storage. Nothing is guessed, it is simply looked up. This is why reusing one password across services is the actual risk, rather than the breach itself, and why a unique password per site contains the damage.
- How often should I check?
- Two to four times a year for your main addresses, plus whenever there is a reason: a provider you have an account with discloses an incident, or verification codes and login attempts appear that were not yours. Have I Been Pwned also offers notifications that alert you when your address turns up in something new, which works better than a reminder in a calendar.
- Does a password manager help?
- It solves the exact problem the chain reaction depends on. Because it remembers an unlimited number of long strings, every service can have its own password, and a breach then stays confined to that one service. Most managers also compare stored entries against known breach data continuously. The price is one strong master password and a second factor on the vault itself.
- What does a clean result mean?
- Only that your address is not in that particular dataset. Breaches that never became public, that nobody has processed yet, or that happened yesterday are missing from every collection. A clean result is good news with a limited reach rather than an all-clear. The measures that work regardless are a unique password per service and a second factor.
- Are the paid dark web monitoring services worth it?
- They largely repackage what free services already surface, wrapped in a dashboard and a subscription. The useful part, being told when your address appears in something new, is available at no cost. Before paying for monitoring, spend the effort on unique passwords and second factors, because monitoring only tells you something happened while those two decide how much it costs you.