haveibeenpwned.com
What HaveIBeenPwned.com is actually for
HaveIBeenPwned.com (HIBP) is a breach exposure lookup service. You type in an email address (and in some cases a phone number), and it tells you whether that identifier appears in breach data sets HIBP has verified and loaded. It also tracks “pastes” (public dumps posted to text sharing sites) separately from “breaches,” which is useful because a paste often signals sloppy exposure even when there wasn’t a classic “company got hacked” story.
The scale is part of why people keep coming back. As of the site’s own counters, it lists 955 “pwned websites” (breaches) and 17,494,305,328 pwned accounts in the corpus.
The site’s core features (and what’s free vs gated)
HIBP has a few distinct services that get mixed together in conversation:
- Email breach search: the classic “is this email in a breach?” check. The public search experience is deliberately simple.
- Pastes: a separate section in results that shows exposures from text-sharing sites / public dumps.
- Pwned Passwords: checks whether a password has appeared in known breach corpuses, without tying passwords to specific emails.
- Notify Me: email alerts when your verified address appears in newly added breach data. It’s double opt-in (you must click a verification link).
- Dashboard: where the “identity-required” features live (sensitive breaches, stealer logs tied to your domain, domain monitoring, API keys). HIBP uses a “send a magic link” sign-in flow rather than passwords for dashboard access.
- Domain search: lets domain owners see which addresses on their domain appear in breaches, but only after proving control of the domain.
- API: for companies and developers integrating breach checks. Some endpoints are paid and rate-limited depending on subscription tier.
The “why this matters” is that each feature has different privacy and abuse risks. HIBP is very explicit that the service is meant to help people respond to breaches, not enable harassment, marketing, or targeting victims. That intent shows up as product decisions: verification steps, rate limits, and limits on what data is ever returned.
Privacy model: what HIBP says it stores (and what it tries not to)
This is the part people argue about, so it’s worth being concrete.
HIBP’s Privacy Policy says it does not collect or store your personal information when you conduct a search; a search retrieves matching data and returns it, but the search itself isn’t “explicitly stored” as a record tied to you. It also says it keeps minimal logs to keep the service running and prevent abuse, and it uses cookies for session persistence rather than ad tracking.
For breach data it loads, HIBP describes storing email addresses (and in limited cases phone numbers stored separately), but not loading names and not linking phone numbers to emails. It also stores “data classes impacted” at the breach level (e.g., whether passwords were present in the original breach) but not a per-email mapping of “this email’s password was exposed.”
And then there’s opt-out, which is a rare thing for a breach corpus. HIBP offers three models, from “remove from public search” to “remove all current and future breaches” to “remove the email entirely,” each with different trade-offs around reappearance in future loads.
Pwned Passwords: the k-anonymity approach that made it widely usable
Pwned Passwords is separate from the email breach database in an important way: it’s intended to be safe enough to integrate everywhere (password managers, browsers, login forms) without exposing passwords.
HIBP describes hashing the password client-side with SHA-1 and sending only the first 5 characters of the hash (“range” querying), following the Cloudflare k-anonymity approach. The server returns a list of hash suffixes and counts for that prefix, so the client can check locally whether the full hash appears. HIBP says it never receives the original password and doesn’t receive enough to recover it.
The site also publishes performance stats that explain why this scales: it claims 18B+ monthly requests for Pwned Passwords and delivery via Cloudflare’s edge network with a very high cache hit ratio. That’s basically the reason this feature became an industry primitive rather than a niche tool.
“Sensitive breaches” and why results can differ depending on how you search
HIBP flags some breaches as “sensitive.” The practical effect is: they don’t show up in public searches, but can be viewed if you verify you control the email address (via the subscription/notification/dash flow). Domain owners who verify control can also see them via domain search.
This is a balancing act. Sensitive breaches are often exactly the ones people most want to hide (think breaches that reveal private life details), but they’re also often the ones where victims most need to know exposure happened. HIBP’s approach is: reduce public discoverability while still letting the affected person (or verified domain owner) access the information.
If you ever see two people get different results for the “same” email, this is one of the biggest reasons—public vs verified access paths.
Stealer logs: a newer category that changes the threat model
HIBP has expanded beyond classic “company breach dump” data into stealer logs—data captured by information-stealing malware when a victim enters credentials into websites. In API documentation, HIBP distinguishes stealer log endpoints and notes they have their own lower rate limits and require higher-tier access (it specifically notes stealer log APIs require a Pwned 5 subscription or higher).
Two important details are easy to miss:
- HIBP emphasizes there are no API endpoints that return a user’s password. Password checking is separate via Pwned Passwords.
- Some stealer-log searches require that the email address being queried is on a domain you’ve already added and verified in the domain dashboard—again, this is about preventing the service becoming a targeting tool.
This stealer-log addition is also why you’ll see HIBP in the news even when there wasn’t a single “brand got breached” headline—because stealer malware aggregates can be massive and cross-site.
The API: why it exists and how it’s constrained
HIBP’s API is meant for organizations building security features: checking customers during signup, monitoring corporate domains, enriching incident response, and so on. The modern model is subscription-based with explicit rate limits and separate limits for certain datasets (like stealer logs by domain). The docs also explain operational tactics, like polling “most recent breach” and only hitting domain search when something new appears, to avoid unnecessary load.
There’s a philosophical line running through the Terms of Use: don’t build services that “ambulance chase” breach victims or exploit the data to disadvantage them, and don’t share API keys. That’s not just legal text—those expectations influence enforcement and how tolerant HIBP is of borderline use cases.
Key takeaways
- HIBP is multiple services: email breach lookup, pastes, notifications, domain search, Pwned Passwords, stealer logs, and an API—each with different privacy and abuse constraints.
- The public search is intentionally limited; verification unlocks sensitive breaches and domain-level views.
- Pwned Passwords uses a k-anonymity “hash prefix” model so integrations can check passwords without sending plaintext.
- Opt-out exists and offers different removal models, which is uncommon for breach corpuses.
- Stealer logs shift HIBP from “breach aftermath” into “credential theft telemetry,” and access is more tightly gated.
FAQ
Is HaveIBeenPwned free to use?
The basic email search and the Pwned Passwords check are available on the public site, while things like domain search dashboards, stealer log APIs, and many API use cases are tied to paid subscriptions and verification flows.
Does HIBP store the email addresses people search for?
HIBP states in its Privacy Policy that it does not collect or store your personal information when you conduct a search, and that it keeps minimal operational logs to keep the service functional and prevent abuse.
If my email is “pwned,” does that mean my password is visible on HIBP?
HIBP says it does not load passwords alongside email addresses in the breach search feature. Passwords are handled separately in Pwned Passwords and are stored as SHA-1 hashes, not tied to a specific email identity.
What’s a “sensitive breach,” and why might it not show up?
Sensitive breaches are not returned in public searches. They can be viewed after verifying ownership of the email address (and are also available to verified domain owners via domain search).
What should I do if I find my email in a breach?
HIBP itself is an exposure indicator, not a remediation tool. The practical next steps are usually: change passwords where reused, enable MFA, and treat breach-specific data classes seriously (e.g., if address/phone details were exposed, expect targeted phishing). HIBP’s notification feature can help you catch new exposures earlier.
Post a Comment