How to Check If Your Password Was Leaked (And What to Do in the Next 10 Minutes)

The threat model behind a leaked password is not what most people picture. Nobody is pointing a cracking rig at your account. Credential stuffing is cheaper: take a list of email-and-password pairs from a breach, feed it into a tool that tries each pair against hundreds of unrelated services, and collect the small percentage that work because the password was reused.

That shifts the important question. "Was my password leaked?" matters less than "where else did I use it?" One leaked password on a forum you forgot about is a non-event. The same password on your email account is a chain reaction, because email is the reset channel for everything else.

Checking takes about four minutes. The triage afterwards takes about ten. The order of the triage is what determines whether it works.

Four ways to check, ranked by what they tell you

1. Your browser already knows

Every major browser now ships a credential checkup that compares your saved logins against known breach corpora, using a privacy-preserving protocol so the plaintext never leaves the device.

Chrome:   chrome://password-manager/checkup
Edge:     edge://wallet/passwords/password-monitor
Firefox:  about:logins   → "Breached websites" banner
Safari:   Settings → Passwords → Security Recommendations

This is the highest-value check and the most ignored, because it reports three distinct problems at once: compromised (this exact pair appeared in a breach), reused (you used this password on multiple sites), and weak (it would fall to a dictionary attack). The reused list is the one to act on even when nothing is flagged as breached, because it is a map of your future blast radius.

2. The Pwned Passwords range API, run locally

Have I Been Pwned's password endpoint is worth understanding rather than just using, because the design is the reason you can trust it.

You hash the password with SHA-1 and send only the first five hex characters of the hash. The server returns every breached-hash suffix that shares that prefix — typically several hundred entries — and you search that list on your own machine. The server learns a five-character prefix shared by millions of possible inputs. That is k-anonymity, and it means a positive or negative result is computed on your device.

Run it yourself:

PW='the-password-you-want-to-test'
HASH=$(printf '%s' "$PW" | sha1sum | cut -d' ' -f1 | tr 'a-z' 'A-Z')
curl -s "https://api.pwnedpasswords.com/range/${HASH:0:5}" | grep "${HASH:5}"

No output means no match in the corpus. A line like A1B2C3...:4821 means that hash appeared in 4,821 breached records. On macOS substitute shasum for sha1sum. Clear the shell history afterwards if you typed the password inline — or better, read it with read -s PW so it never lands in ~/.bash_history.

One refinement: the API accepts an Add-Padding: true request header that pads every response to a uniform number of entries. Without it, the size of the response is a weak side channel for an observer watching your traffic. With it, every prefix looks the same on the wire.

curl -s -H "Add-Padding: true" "https://api.pwnedpasswords.com/range/${HASH:0:5}"

3. Email-based breach search

Searching an email address answers a different question: which services holding your data have been breached. That tells you where to look even when the password itself was never exposed, because a breach dump with your address, phone number, and security-question answers is a social-engineering kit regardless of password hygiene.

The email breach checker here runs that lookup against breach datasets, and Have I Been Pwned remains the canonical source with a free notification service. Email lookups are not k-anonymous the way the password endpoint is — an address lookup has to transmit the address — so use one you are comfortable submitting, and understand that an address is far less sensitive than a password.

4. Your password manager's own report

1Password's Watchtower, Bitwarden's Reports tab, Dashlane's Password Health, and Proton Pass's monitoring all surface breached, reused, weak, and unprotected-by-2FA entries across your whole vault at once. If you already pay for a manager, this is the most complete view available to you and it takes one click.

The ten-minute triage, in the order that works

People do these steps in the wrong order constantly, and the wrong order lets an attacker keep access through every change you make.

Minute 0–2: the email account, before anything else

Whoever controls your inbox controls password resets on every service you own. Change that password first, to something long and unique. Everything downstream is pointless until this is done — resetting your bank password while an attacker reads your mail just shows them the reset link.

Minute 2–4: revoke every active session

This is the step that gets skipped, and it is the step that evicts an intruder. A password change does not universally invalidate existing sessions; whether it does is a per-service implementation choice. An attacker holding a valid session cookie keeps working through your password change unless you explicitly terminate it.

Google:     myaccount.google.com/device-activity  → sign out each device
Microsoft:  account.microsoft.com/activity        → Recent activity
Apple:      Settings → [name] → device list       → Remove from account
Meta/IG:    Settings → Password and security → Where you're logged in
GitHub:     Settings → Sessions                   → Revoke all
Slack:      Account settings → Sign out all other sessions

While you are there, check app passwords and third-party OAuth grants. An app password survives a password change by design, and an authorised third-party app keeps its token. Both are standard persistence mechanisms, and both look innocuous in a settings page nobody reads.

Minute 4–7: audit what an attacker may have added

Access is one thing; durable access is the goal. Four places to check, in descending order of how often they are abused:

1. Mail forwarding and filters. A rule that forwards all mail to an external address, or that matches "password reset" and routes it to trash, means the attacker sees your resets and you do not. In Gmail: Settings → Forwarding and POP/IMAP, then Settings → Filters and Blocked Addresses. In Outlook: Settings → Mail → Forwarding, then Rules.
2. Recovery email and phone. An added recovery channel is a permanent back door. Remove anything unfamiliar.
3. Registered MFA methods. An extra authenticator app or security key enrolled by someone else defeats your MFA entirely. Remove unknown entries and regenerate recovery codes — the old ones should be treated as burned.
4. Connected devices and trusted browsers. "Don't ask again on this device" flags persist. Clear them.

Minute 7–10: the reuse list

Now work down the list your browser checkup gave you, ordered by consequence rather than alphabetically:

Tier 1 and 2 today. The rest over the week. Trying to do all of them in one sitting is how people abandon the task halfway through.

Breach type determines urgency

Not every notification deserves the same reaction. What was actually exposed changes the response.

The hashing-algorithm row is the one worth internalising. A breach of a site using bcrypt with a sensible cost factor or Argon2id buys an attacker very little; the same breach against unsalted MD5 is functionally a plaintext dump. The reasons are laid out in PBKDF2 vs bcrypt vs Argon2, and it is why "they only got hashes" is sometimes reassuring and sometimes meaningless.

Why 90-day rotation is the wrong habit

NIST Special Publication 800-63B — the US federal digital identity guidelines — says verifiers should not require memorised secrets to be changed arbitrarily or periodically, and should not impose composition rules such as mandatory mixes of character classes. It recommends instead that new passwords be screened against lists of known-compromised values.

The reasoning is behavioural. Forced quarterly rotation produces Summer2026!, then Autumn2026!. The attacker who had the first one guesses the second. Meanwhile the user, now managing predictable variants across dozens of sites, reuses more rather than less.

The modern model is narrower and more effective:

• Long and unique per site, generated rather than invented.
• Screened against breach corpora at creation time.
• Rotated on evidence of compromise, not on a calendar.
• Backed by a second factor, because the password stops being the only thing that matters.

If you want to pressure-test a candidate before committing to it, the password strength checker evaluates it locally, and the password generator produces values that are unique by construction.

Making the next breach a non-event

Checking is reactive. Three changes make the next leak irrelevant rather than urgent.

Unique passwords, generated by a manager. This is the whole fix. Credential stuffing works because of reuse and fails without it. Every other control on this page reduces damage; this one removes the mechanism.

Passkeys wherever offered. A passkey is a key pair with the private half held on your device, so a server breach exposes a public key that is useless to an attacker. There is no shared secret to leak. Coverage is partial but growing, and how passkeys change the login problem covers both what they fix and what they leave open.

A second factor that is not SMS. SIM-swap attacks make SMS the weakest widely-offered option. An authenticator app is a large step up, and a hardware security key is phishing-resistant in a way nothing else on the list is.

Per-service email aliases. Give each site its own address — plus-addressing (you+vendorname@gmail.com) in the simplest case, a dedicated alias provider for stronger separation. When one starts receiving phishing, you know exactly which vendor leaked, and you can disable that address without touching your real inbox.

The part that survives a perfect password reset

Two gaps remain after everything above, and both are about the session rather than the credential.

The first is stolen session cookies. Modern infostealer malware exfiltrates cookie databases directly, because a valid session cookie replays an already-authenticated session and skips both the password and the MFA prompt. Rotating the password does not help unless the service also invalidates the session server-side — which is exactly why the revoke-sessions step sits at minute two rather than minute nine. Session hijacking covers the mechanics and the defences that actually bind a session to a device.

The second is physical. A hardened account with a generated password, a hardware key, and clean recovery settings is still fully readable to anyone who walks up to the unlocked laptop where it is already open. Account security and session security are different layers; for the handful of tabs where that matters, a tab-level unlock prompt such as Locksy gates the contents of those specific tabs without closing them.

Set up monitoring, then stop thinking about it

1. Subscribe to breach notifications for every address you use at haveibeenpwned.com/NotifyMe.
2. Leave your browser's automatic breach warning on — Chrome and Edge check saved credentials against breach corpora on sign-in by default.
3. Enable your password manager's breach alerting if it has it.
4. Diary a quarterly ten-minute pass over the checkup page. Not to rotate on schedule, but to catch new flags and shrink the reuse list.

The goal is not zero breaches — the services you use will be breached, and you have no control over that. The goal is that each one costs you a single password change on a single site, instead of an afternoon.