Frequently Asked Questions

My password appears in a leaked database. Do I have to change my email address?

It is sufficient if you change the password for all of the user accounts that use this email address.

The password for my email address was stolen. Does this mean that only the password of my email account has been affected?

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.

Why can’t any details about the affected data be given in the response to my email?

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).

Can I get detailed information on my leaked data?

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)

I have already changed my password. So why does a leaked password alert still appear in subsequent inquires?

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.

How does a reply email look and from what email address is it sent?

See Response Emails.

The CAPTCHA that must be entered is hard to read. Why don’t you use simpler CAPTCHAs?

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.

How is the service protected from tampering?

  1. A CAPTCHA is used to thwart automated queries.

    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.

  2. We keep the bare minimum of information in our database.

    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.

In what form is the leaked data stored?

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:

LeakDateEmail addressPasswordCredit card...
Leak 1Jan. 201453153f4e83586c1c1ca406ffeec173c0ff90f9a3YesNo...
Leak 2Apr. 2014c42b947f516cf6c5ccd88fa9aff254d0b25e35fdNoYes...

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: address is then obfuscated with a cryptographic procedure:

Obfuscation process( = 53153f4e83586c1c1ca406ffeec173c0ff90f9a3

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.