Docuboxer
By Sergio Alonzo Piña··7 min read

Your password was in a data breach. Now what?

Showing up in a breach doesn't mean you were hacked — it means that password is burned. What to do in the first hour, and how to check without exposing it.

A breach alert does not mean somebody logged into your account. It means something narrower and far more actionable: that exact password string now sits in public credential dumps, loaded into tools that replay it automatically against other services. The job in front of you is not panic, it's retiring that string everywhere today. To find out whether yours is on those lists, the pwned password checker runs the lookup inside your browser and never sends the password anywhere — the mechanism is worth understanding, and it's explained below.

Where the warning came from

Most people land here after a nudge from their own device: Chrome's password checkup, Apple's "this password has appeared in a data leak" banner, or a notification from a password manager. None of those are alerts about your account being accessed. They are the result of comparing your saved credentials against aggregated breach corpora — the same public data anyone else can query.

Those corpora exist because breached databases get dumped, cleaned, merged and traded. They are the raw material for credential stuffing: taking known username and password pairs and firing them at hundreds of other sites, on the well-founded assumption that reuse is nearly universal. The site that leaked is often irrelevant to the damage. What matters is every other place you typed the same thing.

The first hour, in the right order

Sequence beats speed here. The classic mistake is rotating a dozen low-stakes logins first and leaving email until last.

  1. Email first. Your inbox is the master key — whoever controls it can trigger a password reset almost anywhere else. Change that password before anything else.
  2. Turn on two-factor authentication for that inbox immediately. This is the single step that downgrades a leaked password from an emergency to an inconvenience.
  3. Change it everywhere you reused it, not just on the breached site. Work down by value: banking, anything with a stored card, anything tied to your identity.
  4. Don't make the new one a variant of the old one. Bumping a year or appending an exclamation mark is precisely what rule-based cracking tools generate first.
  5. Revoke active sessions. Most services offer "sign out of all devices" plus a list of authorized apps and app-specific passwords. Changing a password does not always evict someone already inside.
  6. Check your mail forwarding rules and filters. A quiet rule that BCCs everything to an outside address is the standard way to keep access after losing the password, and it survives the reset.

How a password gets checked without being sent

This is the part that decides whether a breach checker deserves your trust, and it has a proper name: k-anonymity. The flow is:

  1. Your browser hashes the password with SHA-1 using the browser's own crypto API. The plaintext never leaves the device.
  2. Of the 40 characters in that hash, only the first five are sent. Never the full hash, and never the password.
  3. The service returns every hash suffix sharing that five-character prefix — typically several hundred of them — each with a count of how often it appears in known breaches.
  4. The only revealing step, matching your suffix against that list, happens locally in your browser.

The server therefore learns that somebody asked about a prefix shared by hundreds of unrelated passwords, and nothing more: not which one was yours, not whether it matched. The request also asks for padding, so an observer watching network traffic can't infer the answer from the size of the response.

One honest caveat about SHA-1: it is cryptographically broken for signatures and should never be relied on for protection. It isn't protecting anything here — it's an identifier inside the protocol, which is exactly how the Pwned Passwords API defines it. If you want to watch hash functions behave, the hash generator computes them locally.

Which second factor to pick

They are not equivalent. A hardware security key or a passkey is the strongest option, because it is bound to the real domain and simply won't authenticate against a lookalike phishing page. An authenticator app producing time-based codes is the sensible middle ground for most accounts. SMS is the weakest — SIM swapping is a practical, well-documented attack — but it still beats no second factor by a wide margin. Store your recovery codes somewhere that isn't the account you're protecting.

What a clean result does not prove

"Not found in any breach" is good news with fine print. It means the password isn't in the public corpora queried today. It says nothing about breaches still unpublished, breaches that will never be disclosed, or the one that happens next month at a service where you're using it right now.

It also says nothing about strength. A freshly invented password that is short and predictable will be absent from every list and still fall to a dictionary attack with mangling rules. Breach exposure and guessability are two separate questions — is it burned? and is it guessable? — and a password only passes if the answer to both is no.

Choosing the replacement

Length does more work than exotic symbols. A long random string, or a long nonsense passphrase, holds up far better than eight characters padded with substitutions like @ for a, which cracking rules expanded years ago. The decisive property, though, is being unique per service — that alone breaks credential stuffing, because a leak at one site stops contaminating everything else you own.

Since nobody memorizes dozens of unique strings, the missing piece is a password manager: it generates, stores and fills, leaving you one long master password to remember. For creating replacements one at a time, the password generator builds them in your browser and scores their strength with no network call at all. And if the exposure isn't your logins but credentials pasted into code or log files, the exposed credential scanner finds API keys and tokens before they reach a public repository.

Frequently asked questions

Does a breach alert mean someone hacked my account?

Usually not. The alert means that exact password string appears in credential dumps circulating publicly, not that anyone signed in as you. The real threat is credential stuffing: attackers replay those username and password pairs against other services at scale, betting that you reused it. If you did reuse it, those other accounts are the exposure — not necessarily the breached site.

Is it safe to type my password into a site that checks for breaches?

Only if the site never sends it. The k-anonymity protocol makes the check possible without transmitting the password or its full hash: your browser computes a SHA-1 hash and sends only the first five characters. The service returns every hash starting with those characters, and the final comparison happens on your device. If a checker doesn't explain its method, assume it uploads what you type.

Why change the password everywhere if only one site was breached?

Because the burned asset is the password, not the site. Once a string lands in the public lists it gets replayed against email providers, banks, retailers and social platforms with the same username. Changing it only where the breach happened leaves every account you reused it on wide open, and those are usually the ones worth taking.

Should I change my password first or turn on 2FA first?

Change your email password first, because email is the recovery key to everything else, then immediately enable a second factor on that same account. Move to accounts holding money or stored cards next. Rotating a dozen minor passwords while your inbox still has no second factor leaves the highest-value target unprotected.

If my password isn't in any breach, is it strong?

No. A clean result only means it isn't in the public corpora being queried today. It says nothing about breaches that haven't been published, breaches that never will be, or a leak that happens tomorrow — and nothing at all about guessability. A short, patterned password can be perfectly clean and still fall to a dictionary attack in seconds. Clean is not the same as safe.

Do I still need to rotate passwords every 90 days?

That guidance has largely been retired, because forced rotation pushes people toward trivial variations like Spring2025 followed by Spring2026 — a pattern attack tools model explicitly. Long, unique, manager-stored passwords changed for a reason (a known breach, a compromised device, a shoulder-surfed login) protect far better than a calendar reminder.

Check a password without exposing it

Breach lookup via k-anonymity plus a real strength score, entirely in your browser. Free.

Open password checker →

Related tools

You might also like: what a PDF password actually protects and 13 privacy-first developer tools.