41% of Successful Logins Involve a Compromised Password. Here Is How Attackers Use Them.
Cloudflare analyzed traffic from millions of websites between September and November 2024 and found that 41 percent of successful logins involved compromised credentials. Not failed logins. Successful ones. The accounts being accessed were real, the credentials were valid, and in a significant fraction of cases, the person logging in was not the account owner.
This is the credential stuffing problem, and it operates almost entirely on one behavior: password reuse. When a user registers for website A with the same password they use for their email, their bank, and their workplace login, a breach at website A turns one compromised password into four accessible accounts, or forty if they have reused that password at that many services. A 2024 study of 19 billion leaked passwords found that 94 percent were reused or duplicated across accounts. The mathematics of reuse mean that a single breach in an ecosystem of password reuse is not one event. It is a key that fits multiple locks.
The infrastructure attackers use to exploit this at scale is well-documented and widely available. Understanding how it works is necessary context for understanding why checking your credentials against breach data is not a cosmetic security measure.
How Breach Databases Form and Circulate
Data breaches produce structured data: username or email address, hashed or plaintext password, often additional account details. That structured data circulates through multiple channels. Security researchers have tracked the same breach data appearing on criminal forums within hours of a compromise, sometimes before the breached company has identified the incident.
The scale of circulating breach data grew sharply through the 2020s. In June 2026, researchers discovered an open Elasticsearch cluster containing 24 billion credential records, compiled from infostealer malware logs and prior breaches. In 2020 alone, over 193 billion credential stuffing attempts were recorded globally. By 2024, credential stuffing had become the single most common data breach vector, accounting for 22 percent of all breaches, ahead of phishing.
Breach data does not stay in raw form. It is cleaned, deduplicated, merged with data from other breaches, and sorted by domain to make targeting specific services easier. A criminal operator wanting to attack streaming services can buy a list specifically pre-filtered for accounts at those services, with email addresses that have been seen at multiple breaches indicating users who tend to reuse passwords.
Real-world examples illustrate the mechanism precisely. In October 2023, 23andMe disclosed that attackers had accessed user accounts through credential stuffing, using passwords reused from earlier breaches at unrelated services to access genetic data for approximately 6.9 million users. None of the passwords came from 23andMe itself. They came from previous breaches of other companies' databases. The victims had never had a breach at 23andMe, but they had reused passwords from sites that had.
Have I Been Pwned: Building the Check Infrastructure
On December 4, 2013, Australian security researcher Troy Hunt launched Have I Been Pwned with five breached datasets indexed: Adobe Systems, Stratfor, Gawker, Yahoo Voices, and Sony Pictures. Hunt built the service after noticing that breach notification was slow, inconsistent, and often buried in press releases that affected users never saw.
The service grew as Hunt systematically gathered and indexed breach data. By 2024, Have I Been Pwned averaged 160,000 daily visitors, maintained nearly three million active email subscribers, and had indexed records from billions of accounts. The Pwned Passwords database, which tracks individual passwords rather than email addresses, was processing over two billion queries per month.
The Pwned Passwords database contains over 600 million unique passwords drawn from real-world breach data. The value is not theoretical. Attackers do not attempt passwords randomly. They attempt passwords from actual breach lists, because most users choose passwords that have previously been chosen by other users. A password that appears in breach data is a password that is already in an attacker's working list.
How k-Anonymity Makes the Check Safe
The practical problem with checking passwords against any external database is that the check itself becomes a security risk. If you send a password to a remote server to verify whether it appears in breach data, that server now knows your password, and any interception between you and the server also learns it.
In February 2018, British computer scientist Junade Ali designed a solution using a mathematical property called k-anonymity. The protocol works as follows: your password is hashed using SHA-1, and only the first five characters of the resulting hash are sent to the lookup service. The service returns all known breach hashes that start with those same five characters, typically several hundred entries. Your device then performs the comparison locally, checking whether the complete hash of your password appears in the returned list.
No full password is transmitted. No complete hash is transmitted. The five-character prefix cannot be reversed to recover the original password, and it matches a large enough range of possible passwords that the server cannot determine which specific password you are checking. This is the k-anonymity property: the query is indistinguishable from hundreds of other queries that would generate the same prefix.
Cloudflare adopted this API for its own password-checking features. Password managers including 1Password and browsers including Chrome and Firefox use the same protocol to check saved passwords against breach data automatically.
What to Do With the Results
A password that appears in breach data does not necessarily mean your specific account at a specific service was compromised. It means that password is in the lists attackers use to conduct credential stuffing. Even if the password was exposed at a service you no longer use, any other account where you used the same password is at risk.
Conclusion
The remediation steps are mechanical. Change the compromised password immediately at every service where you have used it. Enable two-factor authentication on those accounts. A compromised password combined with two-factor authentication still carries risk but narrows the attack window significantly. Using a password manager to generate unique passwords for each service eliminates the reuse vector entirely.
The check establishes a baseline condition. A password not appearing in any known breach database is not certified safe, but one that has already appeared in breach data should be treated as a shared secret, something that is known to more people than just you and the service you entered it at.
Frequently Asked Questions
What is credential stuffing?
Credential stuffing is when attackers take username and password pairs from one data breach and automatically try them at other services. It succeeds because many people reuse the same password across multiple sites.
How does k-anonymity protect my password when checking for breaches?
Your password is hashed with SHA-1 and only the first 5 characters of the hash are sent to the server. The server returns all matching hash suffixes. Your device does the final comparison locally, so the actual password is never transmitted.
What should I do if my password appeared in a breach?
Change it immediately at every service where you used that password. Enable two-factor authentication on those accounts. Use a password manager to generate and store unique passwords for each service going forward.
Is it safe to check my password using an online breach checker?
Yes, if the tool uses k-anonymity (which ToolHQ's does). The full password or its complete hash is never sent. Only a 5-character hash prefix is transmitted, which cannot be reversed to reveal the original password.