Frequently Asked Questions

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

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

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

Absolutely not! It could be the password of any user account for which you have provided your e-mail as identification. This can be the password of your e-mail account OR of another Internet service.

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

If your data has shown up in a leak, it’s possible that an attacker has already gained access to your e-mail account and can read the answers to your e-mails. To prevent an attacker from accessing more information from other accounts containing the same e-mail 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 (§3 para. 1 BDSG). (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 e-mail look and from what e-mail address is it sent?

See Response E-mails.

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 e-mail 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 e-mail address is not stored in plaintext, but disguised in such a way that only those identities for which the e-mail address is known have access to the information.
The following is an example of the stored data:

LeakDateE-mail addressPasswordCredit card...
Leak 1Jan. 201453153f4e83586c1c1ca406ffeec173c0ff90f9a3YesNo...
Leak 2Apr. 2014c42b947f516cf6c5ccd88fa9aff254d0b25e35fdNoYes...

It is not possible to deduce much from the table if the e-mail address behind it is not known. Suppose user John Doe visits the page and enters his e-mail address: john.doe@domain.com.This address is then obfuscated with a cryptographic procedure:

Obfuscation process(john.doe@domain.com) = 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 e-mail addresses are hidden behind the two database entries. He would have to use the same obfuscation process on all e-mails 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.