A leaked email is not the same as a leaked password. And the leaked password is not yet a foreign login.

Section: Technology & AI Author: V Reading Length: ~27 min Sources and further reading: 22 items Topics: password leak, Have I Been Pwned, Pwned Passwords, k-anonymity, credential stuffing, GDPR, ÚOOÚ SEO / Working Title: How to find out if your password or email has been leaked?

How to find out if your password or email has been leaked? The question sounds simple until we notice that we are not comparing one thing. A leaked email is not a leaked password. The password in the corpus is not "your" password. A finding in the index is not a foreign login. And an empty result is not proof that there was no leak. The article is therefore not looking for a safety button. It looks for which layer you are currently measuring and what is not yet flowing from it.

1. The Have I Been Pwned notification is not a message that someone has just logged in

An email arrives in the morning: your address has appeared in a new Have I Been Pwned entry. The reader opens the page, sees the name of the service and the data category. It comes together in one sentence in my head: someone has my password and it's coming to my inbox. A colleague from IT will tell you not to panic and first separate the address from the password. The lawyer will remind the administrator of the 72-hour deadline under the GDPR. Banker talks about credential stuffing on other sites. The service administrator says that he has sent usersnotification.

At first glance, this is one leak. In fact, each describes a different problem. The reader reads the find as a live session. IT addresses the occurrence of secrets in the corpus. The lawyer talks about the administrator's duty towards the authority and data subjects. Banker means repeated password on another service. The administrator decides whether his incident creates a reportable risk.

Therefore, everyone can be partly right and the joint decision still wrong. One mistake leads to panic and an unnecessary reset to a weaker password. The second leads to peace of mind from an empty result and to continue using the same password on ten sites. HIBP is not an alarm about a login in progress. It is an index of known files and incidents, with its own limits and date.

2. One address has at least six layers

The word "leaked" is used for a dump from a compromised service, a paste on a website, a stealer log from a victim's computer, a stuffing list, and an administrator notification. These words are not interchangeable. When we mix them up, we react badly: we change the password where repeating it elsewhere was a problem, or we write a complaint where there is no identifiable controller in the GDPR regime.

Six layers of one address:

1. Raw material: dump from compromised service, stealer log, stuffing list or paste. Each type is created differently.
2. Index: Have I Been Pwned, Sentinel, password manager or internal service check. Each index has a different corpus and a different latency.
3. Finding: address, password, or a pair of address plus password of the attacker. HIBP does not link a citizen's address and password.
4. Abuse: credential stuffing on other websites, phishing for a reset, selling a logo or logging into an account.
5. Duty of administrator: Article 33 and 34 of the GDPR, documentation of the incident, notification to the ÚOOÚ and any notification to entities ^[13].
6. Account holder response: unique password, change where repeated, more resilient second factor, session control and damage resolution.

An index is not a raw material. A find is not an abuse. The duty of the administrator is not the duty of the citizen. And the user's response should be proportional to the layer they are currently seeing. One does not need to know how stuffing is done. He needs to know why a repeated password gives new life to an old dump.

This layering also changes language. "I have an email leak" is the right beginning, not the end of the diagnosis. It is necessary to add whether it was a service that the person used, what categories of data are listed, whether there was a password, whether the password was unique and whether it was repeated somewhere. Only then does the reaction come. Without this interlude, security turns into a ritual: click, freak out, change something, calm down.

A leaked email is not the same as a leaked password. And the leaked password is not yet a foreign login.

— Jiný Kontext

3. The best reaction is the one whose mistake does not lock you out and open the stuffing

A good security response is not the loudest. It is a response that will reduce risk and not create new ones. Resetting one service unnecessarily is a cheap mistake. Resetting to a short, repeated or forgettable password is worse. Entering the full password into a random "authenticator" is a leak in itself. And peace of mind from an empty index can be expensive if the same password is used elsewhere.

This chart is not meant to replace healthy fear. He has to make it more precise. Account security does not come from a single web response. It arises from the fact that the secret is not repeated, the second factor is not just an easily copied code in every situation, sessions can be checked and one knows when it is no longer an index, but a suspicion of foreign input.

The reaction should also have an order. First of all, access to the account is ensured so that the person does not lock himself out. Then the password is changed where there is a reason. Then it is checked whether the same password did not live elsewhere. Finally, notifications and the second factor that makes sense for the given service are turned on. When the order is reversed, one can lose the recovery channel, overwrite the password with a variant of the old one, or resolve the historical index and leave a live session open.

4. The e-mail in the index is not the password in the index

Have I Been Pwned separates the email address search in the breach from the Pwned Passwords service. At the address, one can see services and categories of data. They don't see their password next to the address. HIBP explains in the FAQ that passwords are not stored in a way that links them to public search addresses ^[4]. This is a safety margin for the service, not a cosmetic detail.

As of 1 September 2026, the HIBP homepage listed 17 796 310 183 indexed accounts and 1 033 pwned sites or incidents ^[1]. These numbers are live global service counters. It measures accounts or addresses in the index, not unique people and not the number of victims in the Czech Republic. One person can have multiple addresses. One address can be in multiple incidents. One incident may contain only email and another a broader set of categories.

Therefore, the practical question is not "am I hacked?" It reads: which service is listed, what categories of data are listed for it, and whether I used a password there that was repeated elsewhere. If so, the problem is not just the old service. It lies in all the places where the same secret has opened the same door.

Data categories are also important because e-mail is often just an identifier for other attacks. You don't have to open an account on your own. However, it can help convincing phishing, reset communication, or pairing with another leak. It does not follow that every address found means harm. It follows that the address in the index has a different weight than the password in the corpus and a different weight than the confirmed foreign session.

5. The password in Pwned Passwords is not "your" password

Pwned Passwords measures the occurrence of secrets in a corpus of known leaked passwords. When a password is found, it doesn't mean the service knows it was yours. It means that the same secret appeared somewhere in the corpus. If you have ever used it, it should be considered public and not suitable for further use.

As of 1 September 2026, Pwned Passwords reported traffic of over 18 billion requests per month, a cache hit of over 99.9%, and 335 edge locations ^[2]. This measures the operation of the service and the integration of password managers, registration forms and manual checks. It does not measure the number of new breaches or the number of people whose password has been compromised.

The difference between "password found" and "someone logged in" is crucial. The first is the state of secrecy. The second is an event in a specific account. We solve the secret state by changing everywhere the password was repeated, and with a new unique password. We solve the event in the account with sessions, login logs, service support and, in case of damage, by the bank or the police. One layer should not swallow the other.

6. The stuffing list is not the leak of one company

Credential stuffing is the misuse of already known pairs of credentials against other services. OWASP distinguishes it from brute force and password spraying ^[17]. The point is not to guess the same password over and over. The essence is repeating old secrets where people have used the same password multiple times.

Troy Hunt described the corpus of Synthient Credential Stuffing Threat Data added to HIBP in November 2025. It lists 1 957 476 021 unique email addresses, roughly 1.3 billion unique passwords, and 625 million passwords that HIBP had not seen before ^[6]. The HIBP entry for this corpus describes it as stuffing data, not a single firm leak ^[7].

The same text lists 32 million domains and 394 million addresses in the gmail.com domain, or about 20% of the addresses in this corpus ^[6]. This is not a Gmail leak. It is a sign that a large freemail domain appears in recycled login pairs. Whoever reads this number as a compromise of Google has confused the denominator.

This does not result in instructions for the attack. This results in a defense rule: the old password must not be repeated. If it was repeated, it changes everywhere it was used, not just for the service mentioned in the notification. The new password should not be a variant of the old one. A password manager is not an added convenience. It's a way to stop the recycling of secrets.

Stuffing also explains why old leaks don't disappear just because the old service has died. The value of the address and password pair does not lie only in the original website. It lies in the possibility that the person used the same secret elsewhere. Therefore, the defense does not consist in finding the original culprit at all costs. It consists in the fact that the repetition is removed and future logins do not rely on the same secret.

7. Stealer log is not the same as operator leak

A stealer log is created differently than a leak of the operator's database. Malware on the victim's device can collect stored credentials, cookies, or other data from the user's environment. Compromise of a business means failure of the service administrator. Both outcomes can end up in the same data market. However, the cause, responsibility and response are different.

In the DBIR 2025 supplement, Verizon reports that compromised data was the initial vector in 22% of breaches out of 9,891 incidents with a known vector, outside of the Error and Misuse categories ^[16]. The same material on 14,742 infostealer devices reports a median of 49% unique passwords across services, meaning that there was a median of 51% repeated passwords in this population of malware victims ^[16]. It is a Verizon dataset, not the Czech population and not all users.

Verizon also reports that in SSO logons, credential stuffing accounted for a median of 19 % of authentication attempts across 2,301 organizations ^[16]. This is measured in organizations and logos, not the number of logins to your account. Still, it shows a mechanism: a repeated password turns an old leak into ongoing pressure on other services.

Stealer log adds one more lesson. Sometimes it is not enough to change the password for the service that appeared in the index. If the problem was with the device, one must solve the device. Updates, malware removal, browser and session checking belong to a different layer than email discovery. This text does not give a procedure for obtaining logos or using them. It just separates the cause: a failure at the operator is not the same as an infected user device.

8. K-anonymity measures the prefix. No trust in a random checker

Pwned Passwords uses a k-anonymous search model. The client calculates the SHA-1 fingerprint of the password and sends only the first 5 hex characters. There are 1 048 576 possible prefixes because 16^5 ^[5]. The server returns the corresponding suffixes and occurrence counts. The full password does not leave the device as plain text or as a full hash.

HIBP API v3 describes range search and maintaining the partial query principle ^[3]. So the server does not see the whole password. They only see the fingerprint prefix. This doesn't mean you should send your password anywhere the word "checker" appears. It means that there is a specific more secure mechanism used by official Pwned Passwords and some password managers.

NIST SP 800-63B recommends validating chosen passwords against lists of known compromised values ^[8]. This is a recommendation for proper password management. It is not a universal Czech legal obligation for all administrators to use HIBP. And it's no excuse for collecting full passwords into a random web form.

K-anonymity plays a modest role here. It doesn't say the password is strong. It doesn't say the account is secure. It tells whether the given secret appeared in the known corpus. A weak but not leaked password can still be a bad choice. A strong and unique password, once in the public corpus, is to be deprecated. Leakage control is one brake, not the entire safety system.

How to test a password without sending the secret

Use the official Pwned Passwords or a password manager that performs the check with k-anonymity. Do not enter the full password on an unknown site, do not send it by e-mail and do not test foreign combinations. The purpose is to see if your secret is no longer a secret. Not to check whether it is possible to enter somewhere with a foreign combination.

9. Sentinel is not the same as Have I Been Pwned

CZ.NIC described Sentinel View as a tool that allows you to check passwords against data from the Turris Sentinel network and uses the partial hash principle ^[18]. Another CZ.NIC text combines the rules for creating a password with the Turris Sentinel Report ^[19]. It's a close defense idea: not to send the whole secret, but to compare it to a corpus of known occurrences.

However, Sentinel is not a HIBP. It has a different data source, a different scope and a different mission. A blank result in Sentinel does not clear HIBP. An empty HIBP does not clean the Sentinel. Neither index can promise that a password has never been leaked or that no one is currently trying to log in. The absence of a finding is just the absence of a finding in the given corpus.

This is why indexes should not be used as an authority contest. One can capture the password from its environment, the second a global public dump, the third a check inside the password manager. A discrepancy between them does not necessarily mean an error. It often means a different source, different timing and different inclusion rules. The defense conclusion is simple: the found password is discarded, the unfound password is not repeated anyway.

For the Czech user, the value of Sentinel is that it offers another defensive view without having to work with offensive lists. If the service reports an occurrence, the password is not used. If it does not report anything, the uniqueness of the password and the second factor still apply. Security must not rely on a single blank page.

10. Notification of the ÚOOÚ is not a complaint of the entity

Article 33 of the GDPR states that the controller shall report a breach of personal data security to the supervisory authority as soon as possible within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons ^[13]. ÚOOÚ has its own information and form for this ^[11]. This period is the responsibility of the administrator. Not a citizen.

In the annual report for 2024, ÚOOÚ lists 336 notifications of breaches of personal data security ^[9]. In its annual report for 2025, it lists 392 announcements, the highest number since the GDPR took effect ^[10]. These numbers measure administrators' reporting to the Czech Supervisory Authority. It does not measure the number of leaked passwords of citizens, the number of records in HIBP or the size of specific dumps.

The subject's complaint is another matter. In the report for 2025, the ÚOOÚ reports 3,854 submissions, of which 2,514 were complaints and 1,340 initiatives, 68% more than in 2024 ^[10]. It's a mix of GDPR agendas, not just password leaks. A complaint under Article 77 requires a relationship with a specific administrator and an authenticated procedure with the ÚOOÚ ^{[12] [13]}. A finding in HIBP alone does not necessarily tell who and what can be blamed.

11. Notice to subjects is not the same as HIBP index

Article 34 of the GDPR regulates the notification of a breach of the security of the data subject's personal data if it is likely that the breach will result in a high risk to the rights and freedoms of natural persons ^[13]. The EDPB and the original WP29 issued WP250 guidance on this ^[14]. This notification comes from an administrator. It is supposed to say what happened, what information concerns the person and what to do.

HIBP is a different institution in and out of quotes. Indexes known publicly leaked files and incidents. It may show an address in an ancient dump. It does not have to have a non-public incident that the administrator has reported to subjects. And it may have a historical record that the administrator no longer communicates with. Being in one does not mean being in the other.

Before filing a complaint with the ÚOOÚ

First, ask three questions. Who is the administrator? What duty should have been breached? What document do you have: a notice, a communication, a request rejection, or just a public index? Article 78(2) GDPR works with informing the complainant of the progress or outcome of the complaint within three months ^[13]. It is not a deadline for deletion from HIBP.

12. Finding in the index is not proof of someone else's login. An empty result is not a clean bill

The HIBP FAQ explicitly works with the limit of absence of evidence: absence of evidence is not evidence of absence ^[4]. When an address is not found, we don't know it was never leaked. We only know that it is not in that index. When it is found, we don't know that someone has just logged in. We know she appeared in a known file or incident.

This double negation is uncomfortable but liberating. It does not give certainty, but it prevents the wrong conclusion. The finding leads to scrutiny, not panic. An empty result leads to maintaining good habits, not repeating passwords. An index is not a session watchdog. They cannot see the current login to the bank, e-mail or social network.

If a foreign login is suspected, the procedure changes. Sessions, signed-in devices, mail forwarding rules, password changes, second factor, and service notifications are checked. In case of damage or attempted financial abuse, the bank, the service operator and, depending on the circumstances, the police are responsible. This is no longer a leak index article.

The password manager's warning should be read with the same caution. When a password manager reports that a password has been compromised, it usually doesn't say that someone opened a specific account. It says that the secret matches a known compromised value or record in the monitored service. It is a reason to exchange secrets and remove reuse. It is not in itself proof of damage.

An empty result is not a clean bill. The find is not currently logged in.

— Jiný Kontext

13. MFA reduces stuffing. It won't stop phishing where you enter the password yourself

The second factor reduces the impact of a repeated password. If the attacker knows the old email and password pair, the second factor can prevent login. This is why MFA makes sense even after years of old leaks. However, it is not a bulletproof shield against every channel.

Phishing, in which a person himself enters a password and other code into a fraudulent interface, is a different mechanism than the historical occurrence of a password in a corpus. This text does not describe circumvention techniques or a real-time attack. Just a distinction: HIBP shows a historical finding in known data. Phishing is a live channel that can bypass a good habit if a person follows the wrong link.

Hence the sober rule. Once found, the password, reuse and MFA are resolved. In the case of a suspicious link, verification outside the link, direct entry of the service address and contact via a known channel are solved. One defense is not a substitute for another. A password in Pwned Passwords is not phishing proof, but a repeated phishing password cheapens the consequences.

14. A sensitive breach is not the same as a publicly searchable dump

HIBP distinguishes sensitive breaches that are not publicly searchable without verifying ownership of the mailbox. The FAQ listed a total of 87 sensitive breaches and 2 retired breaches as of 1 September 2026 ^[4]. This measures the classification within HIBP, not the sensitivity of every real leak in the world.

The reason is simple. Some incidents themselves reveal sensitive information just because the person was on duty. A public response of "yes, this address is in this incident" could cause new harm. Therefore, the service has a mode where it is necessary to verify ownership of the mailbox. So the index is not just a database. It is also a decision of what can be shown to whom.

The same FAQ mentions plus-aliasing for about 0.03% of addresses and explains that the service does not fully respect it ^[4]. A small number can have a big practical impact. If a person uses an address of the type name+service@domain, finding or not finding can be read incorrectly. Again, this is not a clean bill. This is a technical index rule.

15. ENISA sixty percent of phishing is not the Czech share of leaked passwords

ENISA's Threat Landscape 2025 states that phishing accounted for around 60% of observed cases as an intrusion vector between 1 July 2024 and 30 June 2025 ^[15]. At the same time, the material states that 77 % of incidents in the dataset were DDoS and 8.9% of intrusions were related to credential theft ^[15]. These numbers have different denominators.

That is why they must not be included in the sentence about Czech passwords. ENISA measures the European threat landscape and incident categories in its dataset. HIBP measures known breaches and addresses in the index. ÚOOÚ measures notification of administrators and complaints. Verizon measures its incidents and organizations. Each number can be true and still be inapplicable to another conclusion.

NÚKIB can be a useful context for Czech organizations, but the number of incidents in the report on the state of cyber security is not a proxy for the number of citizens with a password in HIBP ^[21]. Europol, in turn, describes the market for compromised accounts and the crime surrounding them ^[22]. This helps to understand the attackers' motivations. It is not a guide and it is not an individual mailbox audit.

16. A short exposure test does not promise safety

The purpose of the test is to determine exposure, not to obtain third-party data and not to test whether the account can be hacked. This must remain visible even in small steps. Own email is checked on the official HIBP. Your own password is checked via Pwned Passwords or a password manager with k-anonymity. Foreign combinations are not attempted. Stuffing lists are not downloaded.

Three find tests

The first test is the address. Enter your own email into the official HIBP and read results by service and data category. Don't go for the "I'm hacked" feeling. Search whether it was email, phone, password hash, profile data, or another category. Set notifications only for your own inbox.

The second test is the password. Authenticate it with k-anonymity only. If found in the corpus, consider it public. Change it wherever it's repeated and don't use a variation of the old password. This sentence is not an attack. It is the closure of the stuffing path.

The third test is the bill. If the service shows extraneous sessions, unknown devices, setting changes or financial damage, HIBP is no longer the main tool. It is about the operation of the account. Changing the password, logging out of sessions, checking the second factor, contacting the service and, in case of damage, the bank or the police take precedence over further searches in the index.

Sentinel View can optionally be added as another corpus ^[18]. If you receive a notification from the administrator according to Article 34 of the GDPR, follow it. If the administrator does not communicate or violates the rights, the complaint under Article 77 is dealt with, not the request for the ÚOOÚ to delete the public index ^{[12] [13]}.

Write down the test result in three columns: address, password, account. The address includes the service and data category. The password includes a decision where it is repeated and where it is changed. The account includes session, second factor, and unknown changes. This table is not fancy. However, it is better than the vague "I missed it" sentence because it shows a different step for each line.

17. The question is not whether it leaked. It sounds which layer you are measuring

Account security is not a property of the index. An index can be useful and yet limited. It will show a known occurrence of an address or password. It won't unblock the account, it won't delete data from the internet, it won't confirm the live login and it can't prove that nothing was leaked. This is not a weakness of one service. It is the boundary of the measured layer.

The hidden cost of the word "leak" is the loss of resolution. When email in breach, password in corpus, stuffing list, stealer log, admin notification and foreign session fall into one sentence, the reaction becomes random. He overshoots once. Second time around. And sometimes it opens the very path it was meant to close.

Resolution helps even when nothing is found. An empty result does not release you from password management. It just says that the given index has no matching record. A unique password, a password manager, a meaningful second factor, and session control remain the rule even without the red warning. Safety should not wait for discovery.

Similarly, the finding should not determine a single emotion. It is to determine the next step. The address leads to read categories of data. The password leads to changing the secret. The administrator's notification leads to his instructions. Session leads to account protection. Whoever separates these steps does not have to guess whether to be calm or panic.

Therefore, the right question is not just: "Did I forget my password?" The right question is: "Which layer did I just measure: a known dump, a password fingerprint, a stuffing list, an admin announcement, or a foreign session and what else doesn't it result in?" Only then does it make sense to change your password, read notifications, check sessions or file a complaint. Not because panic is a weakness. Because an inaccurate response is another risk.

So the good answer is neither "all is well" nor "all is lost". A good answer is smaller and more accurate. An email in the index is read as a trace in a known file. A password in Pwned Passwords reads like a secret that is no longer appropriate to use. The stuffing list reads like a warning against repetition. The administrator's notice is read as a legal and practical instruction on a particular incident. And foreign sessions are handled as account traffic, not as another lookup onwebsite.

This does not mean that indexes have no value. It follows that they only have value when the right layer and the right step are attached to them. Have I Been Pwned, Sentinel View or ÚOOÚ notifications will then cease to be one red button. They become a map. A map is not a lock. But without a map, the castle changes blindly.

Related texts in this series

• How to recognise a fraudulent e-mail, SMS or phone call? — attack channel vs. leakage index.
• What is a digital footprint… — HIBP is one layer, not the entire Internet.