An email in a leak is not the same as a password in a leak. And a password in a leak is not yet someone else’s 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 whether your password or email has leaked?

How to find out whether your password or email has leaked? The question sounds simple only until we notice that we are not comparing one thing. An email in a leak is not a password in a leak. A password in a corpus is not “your” password. A hit in an index is not someone else’s login. And an empty result is not proof that no leak occurred. The article is therefore not looking for a safety button. It is looking for which layer you are measuring just now, and what still does not follow from it.

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

In the morning an email arrives: your address has appeared in a new Have I Been Pwned record. The reader opens the page, sees the name of a service and categories of data. In the head that joins into one sentence: someone has my password and is just getting into my inbox. A colleague from IT says not to panic and first to separate the address from the password. A lawyer reminds the controller of the 72-hour period under the GDPR. A banker talks about credential stuffing on other sites. The operator of a service says that it has sent users a notice.

At first glance this is one leak. In fact each person is describing a different problem. The reader reads the hit as a live session. IT treats the occurrence of a secret in a corpus. The lawyer speaks of the controller’s duty towards the authority and data subjects. The banker means a repeated password on another service. The operator asks whether its incident creates a risk that must be notified.

That is why they can all be partly right and a shared decision still wrong. One error leads to panic and an unnecessary reset into a weaker password. The other leads to calm from an empty result and to further use of the same password on ten sites. HIBP is not an alarm about a login happening now. 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 a controller’s notice. These words are not interchangeable. When we swap them, we react badly: we change a password where the problem was reuse elsewhere, or we write a complaint where there is no identifiable controller under the GDPR regime.

Six layers of one address:

1. Raw material: a dump from a compromised service, a stealer log, a stuffing list or a paste. Each type arises differently.
2. Index: Have I Been Pwned, Sentinel, a password manager or an internal check by a service. Each index has a different corpus and a different latency.
3. Hit: an address, a password, or an address-plus-password pair on the attacker’s side. HIBP does not join a citizen’s address and password.
4. Misuse: credential stuffing on other sites, phishing for a reset, sale of a log or a login to an account.
5. Controller’s duty: Articles 33 and 34 GDPR, documentation of the incident, notification to the ÚOOÚ and, where required, notice to data subjects ^[13].
6. Account holder’s response: a unique password, a change where it was reused, a more resilient second factor, a check of sessions and the handling of harm.

An index is not raw material. A hit is not misuse. A controller’s duty is not a citizen’s duty. And the user’s response should be proportionate to the layer they are seeing just now. A person does not need to know how stuffing is done. They need to know why a repeated password gives an old dump a new life.

This layering also changes the language. “I have an email in a leak” is the right start, not the end of a diagnosis. It is necessary to add whether it was a service the person used, what categories of data are listed, whether a password was there, whether the password was unique and whether it was reused somewhere. Only then comes the response. Without that middle sentence, security turns into a ritual: click, take fright, change something, calm down.

An email in a leak is not the same as a password in a leak. And a password in a leak is not yet someone else’s login.

— Jiný Kontext

3. The best response is the one whose error will not lock you out and will not open stuffing

A good security response is not the loudest. It is a response that lowers risk and does not create a new one. An unnecessary reset of one service is a cheap error. A reset into a short, repeated or forgettable password is worse. Entering a full password into a random “checker” is itself a leak. And calm from an empty index can be expensive if the same password is used elsewhere.

This table is not meant to replace a healthy fear. It is meant to make it more precise. The safety of an account does not arise from one web answer. It arises from the fact that a secret is not repeated, that the second factor is not only an easily copied code in every situation, that sessions can be checked and that a person knows when it is no longer an index but a suspicion of someone else’s entry.

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

4. An email in the index is not a password in the index

Have I Been Pwned separates a search for an email address in a breach from the Pwned Passwords service. For an address a person sees services and categories of data. They do not see their password next to the address. HIBP explains in the FAQ that passwords are not stored in a way that would join them to addresses for public search ^[4]. That is a security boundary of 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 websites or incidents ^[1]. These numbers are live counters of a global service. They measure accounts or addresses in the index, not unique people and not the number of victims in the Czech Republic. One person can have more addresses. One address can be in more incidents. One incident can contain only an email and another a broader set of categories.

The practical question is therefore not “am I hacked?”. It is: which service is listed, what categories of data are given for it, and whether I used a password there that was also reused elsewhere. If so, the problem does not lie only with the old service. It lies in all the places where the same secret opened the same door.

Data categories also matter because an email is often only an identifier for further attacks. By itself it need not open an account. It can, however, help convincing phishing, reset communication or pairing with another leak. It does not follow that every found address means harm. It follows that an address in the index has a different weight from a password in a corpus and a different weight from a confirmed session of someone else.

5. A password in Pwned Passwords is not “your” password

Pwned Passwords measures the occurrence of a secret in a corpus of known leaked passwords. When a password is found, that does not mean the service knows it belonged to you. It means that the same secret appeared somewhere in the corpus. If you have ever used it, it is to be treated as public and unfit for further use.

As of 1 September 2026 the Pwned Passwords page listed traffic of more than 18 billion requests a month, a cache hit above 99.9% and 335 edge locations ^[2]. That 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 leaks or the number of people whose password was misused.

The difference between “the password was found” and “someone logged in” is fundamental. The first is the state of a secret. The second is an event in a particular account. The state of a secret is handled by a change everywhere the password was reused, and by a new unique password. An event in an account is handled by sessions, login logs, the support of the service and, in case of harm, the bank or the police. One layer must not swallow the other.

6. A stuffing list is not the leak of one firm

Credential stuffing is the misuse of already known pairs of login data against other services. OWASP distinguishes it from brute force and from password spraying ^[17]. The point is not to guess one password over and over. The point is the reuse of old secrets where people used the same password more than once.

Troy Hunt described the Synthient Credential Stuffing Threat Data corpus added to HIBP in November 2025. He 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 record for this corpus describes it as stuffing data, not as the leak of one firm ^[7].

The same text lists 32 million domains and 394 million addresses on the gmail.com domain, that is approximately 20% of the addresses in this corpus ^[6]. That is not a leak of Gmail. 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.

It does not follow that this is a guide to an attack. It follows a defensive rule: an old password must not be reused. If it was reused, it is changed everywhere it was used, not only at the service named in the notification. The new password is not to be a variant of the old one. A password manager is not extra comfort. It is a way to stop the recycling of secrets.

Stuffing also explains why old leaks do not leave a life only because the old service has vanished. The value of an address-and-password pair does not lie only in the original site. It lies in the possibility that the person used the same secret elsewhere. Defence therefore does not consist in hunting the original culprit at all costs. It consists in the fact that reuse is removed and future logins do not rest on the same secret.

7. A stealer log is not the same as an operator leak

A stealer log arises differently from a leak of an operator’s database. Malware on a victim’s device can collect stored login data, cookies or other data from the user’s environment. Compromise of a firm means a failure at the controller of a service. Both results can end in the same market for data. Cause, responsibility and response are, however, different.

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

Verizon also states that in SSO logs credential stuffing formed a median of 19% of authentication attempts at 2 301 organisations ^[16]. That is a measurement in organisations and logs, not the number of logins to your account. It still shows a mechanism: a repeated password turns an old leak into ongoing pressure on other services.

A stealer log adds one more lesson. Sometimes it is not enough to change the password at the service that appeared in the index. If the problem was on the device, the person must deal with the device. Updates, removal of malicious software, a check of the browser and of sessions belong to a different layer from an email hit. This text does not give a procedure for obtaining logs or using them. It only separates the cause: a failure at the operator is not the same as an infected user device.

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

Pwned Passwords uses a k-anonymous search model. The client computes a SHA-1 hash 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 matching suffixes and counts of occurrence. The full password does not leave the device as readable text or as a whole hash.

HIBP API v3 describes range search and the preservation of the partial-query principle ^[3]. The server therefore does not see the whole password. It sees only the prefix of the hash. That does not mean you should send a password anywhere the word “checker” appears. It means that a concrete, safer mechanism exists, used by official Pwned Passwords and by some password managers.

NIST SP 800-63B recommends checking chosen passwords against lists of known compromised values ^[8]. That is a recommendation for proper password management. It is not a universal Czech legal duty of all controllers to use HIBP in particular. And it is not an excuse for collecting full passwords into a random web form.

K-anonymity here plays a modest role. It does not say that a password is strong. It does not say that an account is safe. It says whether the given secret has appeared in a known corpus. A weak but as yet unleaked password can still be a bad choice. A strong and unique password that once entered a public corpus is to stop being used. A leak check is one brake, not the whole security system.

How to test a password without sending the secret

Use official Pwned Passwords or a password manager that performs the check by k-anonymity. Do not enter a full password on an unknown page, do not send it by email and do not test other people’s combinations. The purpose is to find out whether your secret is no longer a secret. Not to check whether someone else’s combination can be used to enter somewhere.

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

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

Sentinel is not, however, HIBP. It has a different data source, a different scope and a different mission. An empty result in Sentinel does not clear HIBP. An empty HIBP does not clear Sentinel. Neither index can promise that a password has never leaked or that no one is just now trying a login. Absence of a hit is only absence of a hit in the given corpus.

That is why indexes should not be used as a contest of authorities. One can catch a password from its own environment, another a global public dump, a third a check inside a password manager. A contradiction between them need not mean an error. It often means a different source, a different timing and different rules of inclusion. The defensive conclusion is then simple: a found password is retired, an unfound password is still not reused.

For a Czech user the value of Sentinel is that it offers another defensive view without the need to work with attack lists. If the service reports an occurrence, the password is not used. If it reports nothing, uniqueness of the password and a second factor still apply. Security must not rest on one empty page.

10. A notification to the ÚOOÚ is not a data subject’s complaint

Article 33 GDPR says that the controller shall notify a personal-data breach to the supervisory authority, if 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]. The ÚOOÚ has its own information and form for this ^[11]. This period is a duty of the controller. Not of the citizen.

In its annual report for 2024 the ÚOOÚ lists 336 notifications of personal-data breaches ^[9]. In the annual report for 2025 it lists 392 notifications, the highest number since the GDPR took effect ^[10]. These numbers measure notifications by controllers to the Czech supervisory authority. They do not measure the number of leaked passwords of citizens, the number of records in HIBP or the size of particular dumps.

A data subject’s complaint is a different thing. In the report for 2025 the ÚOOÚ lists 3 854 submissions, of which 2 514 were complaints and 1 340 initiatives, 68% more than in 2024 ^[10]. This is a mix of GDPR agendas, not only password leaks. A complaint under Article 77 requires a relation to a particular controller and, at the ÚOOÚ, an authenticated procedure ^{[12] [13]}. A hit in HIBP by itself need not say whom and what can be blamed.

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

Article 34 GDPR regulates notice of a personal-data breach to the data subject if the breach is likely to result in a high risk to the rights and freedoms of natural persons ^[13]. The EDPB and the original WP29 issued the WP250 guidelines on this ^[14]. This notice comes from the controller. It is to say what happened, which data concern the person and what they should do.

HIBP is a different institution, in quotation marks and without them. It indexes known publicly leaked files and incidents. It can show an address in an old dump. It need not have a non-public incident that the controller notified to data subjects. And it can have a historical record with which the controller no longer communicates. Being in one does not mean being in the other.

Before a complaint to the ÚOOÚ

First ask three questions. Who is the controller? Which duty was supposed to have been breached? What document do you have: a notice, a communication, a refusal of a request, or only a public index? Article 78 paragraph 2 GDPR works with informing the complainant of the progress or result of the complaint within three months ^[13]. It is not a period for erasure from HIBP.

12. A hit in the index is not proof of someone else’s login. An empty result is not a clean account

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

This double negation is unpleasant, but liberating. It does not give certainty, but it prevents a wrong conclusion. A hit leads to a check, not to panic. An empty result leads to keeping good habits, not to repeating passwords. An index is not a guardian of sessions. It does not see a current login to a bank, an email or a social network.

If there is a suspicion of someone else’s login, the procedure changes. Sessions, signed-in devices, mail-forwarding rules, password changes, the second factor and notices from the service are checked. In case of harm or an attempt at financial misuse, the bank, the operator of the service and, according to the circumstances, the police are involved. That is no longer an article about an index of leaks.

A password manager’s warning should be read with the same care. When a password manager reports that a password is compromised, it usually does not say that someone opened a particular account. It says that the secret matches a known compromised value or a record in a monitored service. It is a reason to replace the secret and remove reuse. It is not, by itself, proof of harm.

An empty result is not a clean account. A hit is not a login in progress.

— Jiný Kontext

13. MFA lowers stuffing. It does not stop phishing into which you enter the password yourself

A second factor lowers the impact of a repeated password. If an attacker knows an old pair of email and password, a second factor can prevent a login. That is why MFA makes sense even years after old leaks. It is not, however, a bulletproof shield against every channel.

Phishing in which a person themselves enters a password and a further code into a fraudulent interface is a different mechanism from the historical occurrence of a password in a corpus. This text does not describe techniques of circumvention or an attack in real time. The distinction is enough: HIBP shows a historical hit in known data. Phishing is a live channel that can bypass a good habit if a person follows the wrong link.

From that follows a sober rule. After a hit, the password, reuse and MFA are handled. On a suspicious link, verification off the link, direct entry of the service address and contact through a known channel are handled. One defence does not replace the other. A password in Pwned Passwords is not proof of phishing, but a repeated password cheapens the consequences of phishing.

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

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

The reason is simple. Some incidents themselves disclose sensitive information merely by the fact that a person was in the service. A public answer “yes, this address is in this incident” could cause new harm. That is why the service has a mode in which ownership of the mailbox must be verified. An index is therefore not only a database. It is also a decision about what may be shown to whom.

The same FAQ states plus-aliasing at approximately 0.03% of addresses and explains that the service does not fully respect it ^[4]. A small number can have a large practical impact. If a person uses an address of the type name+service@domain, a hit or a non-hit can be read wrongly. Again this is not a clean account. It is a technical rule of the index.

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

ENISA in Threat Landscape 2025 states that phishing formed approximately 60% of observed cases as an intrusion vector in the period from 1 July 2024 to 30 June 2025 ^[15]. At the same time the material states that 77% of incidents in the dataset were DDoS and that, among intrusions, 8.9% concerned credential theft ^[15]. These numbers have different denominators.

That is why they must not be added into a sentence about Czech passwords. ENISA measures the European threat landscape and categories of incidents in its dataset. HIBP measures known breaches and addresses in the index. The ÚOOÚ measures notifications by controllers and complaints. Verizon measures its incidents and organisations. Each number can be true and still unusable for another conclusion.

NÚKIB can be a useful context for Czech organisations, but the number of incidents in the report on the state of cybersecurity is not a proxy for the number of citizens with a password in HIBP ^[21]. Europol, in turn, describes the market in compromised accounts and the crime around them ^[22]. That helps in understanding the motivation of attackers. It is not a guide and it is not an individual audit of a mailbox.

16. A short exposure test does not promise safety

The point of the test is to find exposure, not to obtain other people’s data and not to try whether an account can be broken. That must remain visible even in the small steps. One’s own email is checked on official HIBP. One’s own password is checked through Pwned Passwords or a password manager with k-anonymity. Other people’s combinations are not tried. Stuffing lists are not downloaded.

Three tests of a hit

The first test is the address. Enter your own email into official HIBP and read the results by services and categories of data. Do not look for the feeling “I am hacked”. Look for whether it was an email, a phone, a password hash, profile data or another category. Set notifications only for your own mailbox.

The second test is the password. Check it only by k-anonymity. If it is found in the corpus, treat it as public. Change it everywhere it was reused, and do not use a variant of the old password. This sentence is not an attack. It is the closing of a stuffing path.

The third test is the account. If the service shows someone else’s sessions, unknown devices, changes of settings or financial harm, HIBP is no longer the main tool. It is about the running of the account. A change of password, signing out of sessions, a check of the second factor, contact with the service and, in case of harm, the bank or the police take precedence over a further search in the index.

Optionally, Sentinel View can be added as another corpus ^[18]. If a notice from the controller under Article 34 GDPR arrives, follow it. If the controller does not communicate or breaches rights, a complaint under Article 77 is handled, not a request that the ÚOOÚ erase a public index ^{[12] [13]}.

Write the result of the test in three columns: address, password, account. For the address belong the service and the categories of data. For the password belongs the decision where it was reused and where it is changed. For the account belong sessions, the second factor and unknown changes. This table is not spectacular. It is, however, better than the vague sentence “it leaked on me”, because each row shows a different step.

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

The safety of an account is not a property of an index. An index can be useful and still limited. It will show a known occurrence of an address or a password. It will not unlock an account, it will not delete data from the internet, it will not confirm a live login and it cannot prove that nothing leaked. That 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 distinction. When an email in a breach, a password in a corpus, a stuffing list, a stealer log, a controller’s notice and someone else’s session fall into one sentence, the response becomes random. Once it overshoots. Once it misses. And sometimes it opens exactly the path it was meant to close.

Distinction helps even when nothing was found. An empty result does not release anyone from password management. It only says that the given index has no matching record. A unique password, a password manager, a meaningful second factor and a check of sessions remain the rule even without a red warning. Security is not to wait for a hit.

In the same way a hit is not to determine a single emotion. It is to determine the next step. An address leads to a reading of data categories. A password leads to a change of the secret. A controller’s notice leads to its instructions. A session leads to protection of the account. Whoever separates these steps need not guess whether to be calm or in panic.

The right question is therefore not only: “Did my password leak?” The right question is: “Which layer have I just measured: a known dump, a password hash, a stuffing list, a controller’s notification, or someone else’s session, and what still does not follow from it?” Only then does it make sense to change a password, read a notice, check sessions or file a complaint. Not because panic is a weakness. Because an imprecise response is a further risk.

A good answer is therefore neither “everything is all right” nor “everything is lost”. A good answer is smaller and more precise. An email in the index is read as a trace in a known file. A password in Pwned Passwords is read as a secret that is no longer fit to use. A stuffing list is read as a warning against reuse. A controller’s notice is read as a legal and practical instruction for a particular incident. And someone else’s session is handled as the running of an account, not as a further search on the web.

It does not follow that indexes have no value. It follows that they have value only when the right layer and the right step are bound to them. Have I Been Pwned, Sentinel View or a notice from the ÚOOÚ then cease to be one red button. They become a map. A map is not a lock. But without a map the lock is changed blindly.

Related texts in this series

• How to recognise a fraudulent email, SMS or phone call? — attack channel vs. leak index.
• What is a digital footprint… — HIBP is one layer, not the whole internet.