How to Check If Your Password Was Leaked in a Data Breach

The Scale of the Breach Problem in 2026

Data breaches have become so routine that billions of credentials are now freely available on dark web forums and paste sites. The 2024 "RockYou2024" compilation contained over 10 billion unique passwords — assembled from thousands of breaches spanning two decades of leaked databases. These credentials are traded, merged, and used in "credential stuffing" attacks where attackers automatically try known username/password combinations across hundreds of services simultaneously.

The sobering reality: if you've been online for more than five years, your email address has almost certainly appeared in at least one breach. The question isn't whether you've been breached — it's whether the password associated with your email in the breach database is still in use on any of your current accounts. Even a single reused password creates a domino effect where one breach unlocks multiple accounts.

How Credential Stuffing Attacks Work

Understanding the attack helps you understand why checking matters urgently. When attackers obtain a database of breached credentials (email addresses paired with passwords), they don't manually try each one. They use automated tools that can test thousands of credential pairs per second across multiple target services simultaneously. If you used the same password for an online forum that was breached in 2019 and you're still using that password for your email or banking account today, the attack is trivially straightforward.

Success rates for credential stuffing vary by service but average 0.1-2% — meaning from a database of 100 million credentials, attackers successfully access 100,000 to 2 million accounts. The industry term for these attacks is "ATO" (Account Takeover), and it costs businesses and consumers billions of dollars annually.

The k-Anonymity Model: Checking Without Exposing Your Password

Troy Hunt's HaveIBeenPwned (HIBP) service maintains the most comprehensive freely-available breach database. But checking whether your password is in their database presents an obvious security paradox: to verify that your password wasn't leaked, you'd need to send your password to a server — which is itself a security risk.

The solution is an elegant cryptographic technique called k-Anonymity, designed specifically to solve this problem:

1. Your password is hashed locally on your device using SHA-1, producing a 40-character hexadecimal string
2. Only the first 5 characters of that 40-character hash are transmitted to the HIBP API
3. The HIBP API returns all hash suffixes in its database that start with those same 5 characters — typically 400-800 results per prefix
4. Your device checks locally whether your complete hash appears in the returned list — this comparison happens on your device, never on the server
5. The HIBP server sees only a 5-character prefix shared by hundreds of thousands of different passwords — it cannot determine which password you're checking

This means your actual password — and your complete hash — never leave your device. The API cannot identify your specific password even if it wanted to. An eavesdropper intercepting the API call sees only a 5-character prefix representing ~1 million possible passwords.

What Breach Data Actually Contains

Breach databases vary significantly in what data they contain. Understanding the contents helps assess your risk level:

• Plaintext passwords: Some sites stored passwords in plaintext without any hashing. These breaches are the most dangerous because the password is immediately usable by attackers.
• MD5 hashed passwords: Older sites used MD5 hashing. MD5 passwords are often cracked using rainbow tables and GPU-accelerated brute force within hours or days, especially for common passwords.
• SHA-1 hashed passwords: Similar situation to MD5 — crackable with modern hardware for most passwords under 12 characters without salting.
• bcrypt/Argon2/scrypt hashed passwords: Modern, deliberately slow hashing algorithms designed to resist brute-force cracking. Correctly implemented bcrypt passwords from breaches remain secure for years even if the hash is known.
• Salted hashes: A unique random value added to each password before hashing prevents rainbow table attacks and ensures that two users with identical passwords have different hash values.

Even if your password was stored with a strong algorithm in the breached database, you should still change it — you don't know whether the site correctly implemented the algorithm, what salt length they used, or whether the breach included additional data that could aid cracking.

What to Do Immediately If Your Password Was Leaked

Discovering your password in breach databases requires immediate, systematic action. Prioritize by impact:

1. Change the breached password everywhere you use it. Check your password manager for every site where you've used this password. If you've been reusing passwords, every account using that password is now compromised, not just the one that was breached.
2. Prioritize email accounts first. Your email account controls password resets for virtually every other service. A compromised email account gives attackers access to every account linked to that email address. Change it immediately and enable 2FA.
3. Enable two-factor authentication on all critical accounts. 2FA is the single most effective protection against credential stuffing — even with your correct password, attackers cannot log in without the second factor. Prioritize: email, banking, healthcare, primary social media.
4. Review recent login activity. Every major service provides a login history page. Look for logins from unfamiliar geographic locations, devices, or times. Terminate any suspicious sessions immediately.
5. Check for unauthorized actions. In your bank and financial accounts, review all recent transactions. In email, check for forwarding rules or OAuth authorizations that weren't there before. In social media, look for changes to connected apps.
6. Generate completely new unique passwords. Use a password manager to generate strong, unique, random passwords for every account going forward. Never reuse passwords across services again.

Building a Breach-Resistant Password Strategy

The root cause of credential stuffing vulnerability is password reuse. The permanent solution is adopting a system that makes reuse structurally impossible: a password manager that generates and stores unique random passwords for every account.

• Password length: Each generated password should be at least 16 characters. Modern password managers default to 20+ characters. Longer is always better.
• Randomness: Avoid passwords based on words, names, dates, keyboard patterns, or any predictable formula. Truly random passwords from a password manager are unguessable even with extensive personal information about you.
• Master password design: Your password manager's master password should be a long passphrase — five or more random words strung together. This is both more secure and more memorable than a complex short password. Example: "maple-thunder-capsule-drift-ninety."
• Regular breach monitoring: Set up automated notifications that alert you immediately when your email appears in new breach databases. HIBP offers free email notifications — enroll your primary and secondary email addresses.
• Separate email addresses by risk tier: Use different email addresses for high-security accounts (banking, healthcare) versus low-security accounts (newsletters, trials). Compartmentalization limits breach blast radius.

Monitoring Ongoing: Why One Check Isn't Enough

New breach databases are published continuously — thousands of new breaches are disclosed every year. A password that wasn't in any breach database today may appear in one tomorrow if a service you use is compromised tonight. Ongoing monitoring, rather than a one-time check, is the sustainable approach. Email alert services automatically check your addresses against new breach disclosures as they're added to the database, giving you immediate notification so you can act before attackers exploit the data.