An email breach and a password breach are different emergencies. One means watch for phishing, the other means change passwords now. I run AliasFleet, an email-alias service giving each site its own address, and most breach advice still treats both leaks as a single event. Mix them up and you pay twice over: a password scramble over a leak that only exposed an address, then a shrug at a leak that exposed the password itself.
Blame the alert for the confusion. One red banner tells you that you were pwned and stays silent on the kind. Behind that banner sit two checks built for two different jobs, and Have I Been Pwned keeps them apart on purpose.
Two separate checks, two separate jobs
The email check comes first. Type an address into Have I Been Pwned and it lists the breaches that included it, plus the data classes each one exposed: email addresses, passwords, names, phone numbers, dates of birth. The question it answers is narrow. Where has this address turned up?
The password check works the other way round: type a password into the Pwned Passwords page and it reports whether that password has shown up in known breaches, and how often, which answers a different question: is this secret already burned?
These are not two views of one database, since breach data holds email addresses plus notes on which breaches they appeared in, while Pwned Passwords keeps password hashes in its own system, unconnected to any address or identity. HIBP never links a specific password to a specific person. Ask it which password went with which address and it cannot answer, because it never knew.
Checking a password there is safe by design, because the password gets hashed on your own device and only the first 5 characters of the SHA-1 hash go to the service, which sends back matching suffixes for a local comparison on your device. Your full password and full hash stay put. The name for that setup is k-anonymity, which is what makes this check safe, unlike typing a password into some random breach-checker site.
A clean result proves less than it looks like it does. It only means the password is not indexed in the breaches HIBP knows about. Plenty of breaches never surface, never get verified, or never get loaded. Good news, with limits.
What an email leak hands an attacker
An address alone opens nothing, since nobody logs in with an address by itself. What it hands an attacker is a target and a story: a working address, which site leaked it, and whatever else rode along, a name, a phone number.
What comes next is phishing. A stranger writes as if they were the breached company, your bank, or a delivery firm, quoting real details to sound convincing. The sharpest version lands just after a real breach, when you are half expecting a notice. Scammers either forge a notice around the real incident, or dream up a breach that never happened. Both routes end at the same place: a link, or a bogus reset page.
ESET's write-up of breach-notification scams gives the rule straight: go to the apparent source yourself, never through a reply or a contact detail lifted from the notice.
The email half runs on persuasion. It needs you to do something, click a link or type your password into the wrong page. A reader who types the real site's address by hand beats it without trying.
What a password leak hands an attacker
A password leak hands an attacker something far more direct: a working login pair. No persuasion is needed, and the follow-up is automation.
That attack has a name: credential stuffing. Attackers load leaked pairs into software and let it try them on site after site, unwatched. OWASP describes it as mass login attempts that verify whether stolen pairs still work, and stresses the point people miss: unlike credential cracking, no brute-forcing or guessing is involved. Nobody is guessing anything. The password is already in hand. The only question is where else it opens a door.
Reuse is what makes it work. A Google and Harris Poll survey of 3,000 consumers in 2019 found two in three people reusing one password across several accounts, 51% leaning on a single favourite for most of theirs, and only 24% on a password manager. That survey is seven years old now, and behaviour may have shifted since, but the mechanism has not: one leaked pair unlocks every account sharing it.
Troy Hunt's word for a breached password is burned. Pwned Passwords started in August 2017 with 306 million passwords, on one point: once a password has turned up in a breach, nobody should ever use it again. Billions now, and the service fields more than 18 billion requests a month. That volume tells you how routine the check has become.
There is a second-order effect worth naming. Your password can dodge the breach and the phishing half still gets armed. Attackers now know you have an account there, which writes the fake reset email for them. Password breaches usually carry the email half along. Email breaches do not return the favour.
One table, two responses
Each half wants its own response, on its own clock, in its own order.
| Email breach only | Password breach | |
|---|---|---|
| What leaked | One address, plus any contact fields in the same record | A working login pair, address included |
| Attacker follow-up | Phishing that throws the breach back at you | Credential stuffing, automated logins tried on other sites |
| First move | Expect forged notices. Check through the real site, typed by hand | Change the password at the breached site, then everywhere it was reused |
| Second move | Watch for calls, texts, and emails that weaponise your real details | Switch on two-factor authentication for email, banking, and password manager |
| What NOT to do | Click no links in breach emails, genuine or forged | Changing only the breached site and stopping leaves the hole open: reuse |
| How long it lasts | Targeted phishing can persist for weeks or longer | Until every reused copy is changed |
Before you do anything, read the breach's data classes. They sit on the HIBP result as the line listing what actually left the building. No passwords among them, and you are in the left column. Passwords among them, and you should assume yours is in the dump and work the right column. The breach-response order of operations lays out the full sequence, and the guide to reading your HIBP result explains the flags and data classes.
Why one alias per site changes the email half
Give every site its own alias and an email breach exposes an address that belongs to one site alone. An email alias forwards to your real inbox, which means the site never held your real address at all. Phishing still arrives. It arrives on an address that names its source, and pausing that one alias kills the channel. The real inbox stays clean. Other accounts stay clear, since no other site ever held that address. What would have been months of spam becomes a ten-second cleanup.
To be exact: this makes the email half nearly harmless, but it does nothing for the password half, because an alias is an address, not a password, and a leaked password still needs changing everywhere it was reused. Anyone pitching aliases as a password fix is pitching the wrong tool.
The leak-tracing guide puts the mechanism to work: spam lands on one alias, the address itself fingers the source, and you pause it. The alias set-up guide takes about two minutes. Begin with the accounts you care about most.
Which check do I run first?
Do both, in this order: first, search your email address on Have I Been Pwned and read the data classes for each breach it names, which tells you which column of the table you are in. Second, run your current passwords through Pwned Passwords, starting with your email account, then banking, then everything else. A hit means that password is finished. Change it everywhere it appears, and do not swap in a near-miss version, because attackers commonly test obvious variations.
Then fix the setup so the next breach costs less. A different password per site, kept in a password manager, plus two-factor authentication where it counts, and one alias per site, so the next email leak gives itself away. NIST's password guidance makes verifiers check new passwords against lists of known compromised values, previous breach corpuses included, which is what the Pwned Passwords service implements, and the standard treats a breached password as unusable, so do the same.
This covers the two common breach types, email-only and password-included, while a breach exposing ID numbers, financial details, or health data goes past passwords into fraud and identity theft. They need the full recovery steps in the breach-response guide; the table does not cover it. If those fields were in your breach, start with that guide.
The one-sentence version
An email breach means someone knows where to find you, while a password breach means someone holds your key. Watch for the first. Change the locks after the second, and give every site its own address, so the next time only one of them can ever leak.
