It is sufficient if you change the password for all of the user accounts that use this email address.
Absolutely not! It could be the password of any user account for which you have provided your email as identification. This can be the password of your email account OR of another Internet service.
If your data has shown up in a leak, it’s possible that an attacker has already gained access to your email account and can read the answers to your emails. To prevent an attacker from accessing more information from other accounts containing the same email address, we don’t provide concrete data (such as cleartext passwords).
We can’t provide any information about the specific contents of leaks (such as passwords and bank account data) if requested. This is because the origin of the record of the Identity Leak Checker service does not permit explicit assignment to one individual (Article 4, GDPR). (See also Privacy Statement)
The Identity Leak Checker only indicates whether your password has been found in a leak. The Leak Checker says nothing about whether this password still functions for the affected user account. Because your password is still found in the corresponding leak, the website continues to issue a warning.
See Response Emails.
The simpler a CAPTCHA for the user to decipher, the easier it also is for a computer program to decipher automatically. The CAPTCHA method we use is not something we have developed ourselves but is from Google. This procedure is currently one of the few that can distinguish between human and machine with a relatively high degree of reliability.
To prevent the Identity Leak Checker from carrying out queries automatically, a CAPTCHA is required by the website after the 3rd completion of a successful query. While this CAPTCHA is relatively easy for a person to render, it is relatively difficult for a machine. This makes it very difficult for automated queries to be performed in large number.
In order to prevent an attacker from exploiting data from our service, our database scheme is reduced to the absolute minimum of necessary data. This scheme is explained in more detail in the section In what form is the leaked data stored. In the event that an attacker succeeded in hacking our website - despite our protective measures - he would be able to read only one database and that with extremely limited information content.
When storing data, the user’s privacy is important to us. This means that for every identity found in a data leak, we store only the data that is absolutely necessary to offer our service. Only the email address and the nature or type of information that has been made public together with the source and publication date is stored for an identity. Additionally, the email address is not stored in plaintext, but disguised in such a way that only those identities for which the email address is known have access to the information.
The following is an example of the stored data:
| Leak | Date | Email address | Password | Credit card | ... |
|---|---|---|---|---|---|
| Leak 1 | Jan. 2014 | 53153f4e83586c1c1ca406ffeec173c0ff90f9a3 | Yes | No | ... |
| Leak 2 | Apr. 2014 | c42b947f516cf6c5ccd88fa9aff254d0b25e35fd | No | Yes | ... |
It is not possible to deduce much from the table if the email address behind it is not known. Suppose user John Doe visits the page and enters his email address: john.doe@domain.com.This address is then obfuscated with a cryptographic procedure:
The result can now be looked up in the table and it is evident that that the password of user John Doe was found in a data leak. An attacker who was able to gain access to the database would not be able to figure out which email addresses are hidden behind the two database entries. He would have to use the same obfuscation process on all emails addresses because the obfuscation cannot be recalculated. If the attacker happens to find the counterpart for an obfuscated mail by accident, he would only have access to the data for one identity. But even the given data would not be of much use to an attacker.