What’s in the dataset, and what isn’t.
Short version: the dataset is a list of salted password hashes with category tags. It holds no email addresses, usernames, user IDs or source sites. Raw breach material is processed to extract passwords, hashed, and deleted. We cannot tell whose password any entry is. That is the point, not a limitation.
What an entry is
| Field | In the dataset? |
|---|---|
| The password | As a salted SHA-1 hash only. SHA-1("Salted for knownpass.com: " + password), the same value your client computes. |
| Categories | Yes. Where the password was seen: website leaks, malware leaks, password lists, wordlists, common, masks & patterns, brute-force space, tailored. |
| Email, username, user ID | Never. Discarded during ingestion, before anything reaches the index. |
| The site or breach it came from | Never. A category is kept, the source is not. |
| Date, IP, device or browser data | Never. Stealer logs carry all of these; only the password field survives. |
| Number of independent sources | Kept for ranking, never served. [confirm: keep this row only if a per-entry source count is kept for ranking; otherwise delete it] |
An entry cannot be traced back to a person, by us or by anyone who obtained the dataset. There is nothing in it to trace.
Where it comes from
We ingest
- breach compilations that already circulate publicly
- info-stealer log dumps that already circulate publicly, reduced to the password field
- published cracking wordlists and dictionaries, including language-specific ones
- generated material: masks, predictable patterns, and every combination of 1 to 6 standard characters
- tailored patterns generated from public information about a customer’s organization, at that customer’s request
We refuse
- paying for data, in any form [confirm]
- private or pre-release access to breaches; we are not in the business of infiltrating anything
- material offered under an NDA or with usage restrictions we can’t honour
- anything gathered by accessing someone else’s accounts or systems
- anything from our customers’ API traffic; we never see a password there, so there is nothing to take
How raw material becomes an entry
- A raw file lands in an isolated ingestion environment, separate from the API and the index. [confirm]
- The password field is extracted. Every other field in the record (email, username, site, IP, cookies, browser data) is dropped at this step.
- Strings that are plainly an email address or a phone number are dropped as well. They are identifiers, not passwords worth indexing, and the reference client’s local username check covers them.
- What remains is hashed with the public salt and tagged with a category.
- The raw file is deleted, at the latest [N] days after it arrived.
- The index receives hashes and tags. Nothing else exists to receive.
Raw material contains personal data for the time it takes to run step 2. That short window is the only point where knownPass processes anything that relates to an identifiable person, and it is the part of this page a data-protection officer should read twice.
Why we can’t tell whose password it is
A password on its own is not linked to anyone. 123456 belongs to millions of people; a stronger password still belongs to everyone who happened to choose it. We hold no identifiers, so we cannot look a person up, and neither can anyone else with a copy of the dataset.
GDPR accounts for this. Where a controller can show that it cannot identify the person behind the data, the rights of access, correction and erasure do not apply to that data, because there is nothing to find (Article 11). This is why we decline requests to remove a password: we cannot verify that it is yours, and removing it would stop protecting everyone else who uses it. If a password of yours is in there, the fix that helps you is to stop using it, everywhere.
What we can act on is customer data: the email address on an API key or a design-partner application. That is covered in the privacy policy, and privacy@knownpass.com handles it.
The legal basis, in one paragraph
The ingestion step touches raw material that contains personal data, briefly. We process it on the basis of legitimate interest in network and information security (GDPR Article 6(1)(f); Recital 49 names this interest explicitly). Screening passwords against known-compromised values is a recognised security control (NIST SP 800-63B), the processing is limited to extracting and hashing the password field, nothing that identifies a person is retained, and the outcome protects the very people whose data was leaked. The balancing assessment and the data-protection impact assessment are documented and available to customers under NDA. [confirm: prepare both documents before publishing this sentence, or change it to “are being prepared”] This page describes practice; it is not legal advice.
Tailored datasets
A tailored dataset is generated from public information about your organization (your domain, names, products, places, years) and from anything you choose to add. It is stored per account, never merged into the shared index [confirm], and deleted [N] days after the account closes or on request. It contains generated candidates, not your users’ passwords; we never see those.
Hosting and processors
- The index and the API run on [provider], [region], in the EU.
- Processors: [hosting provider]; [email delivery provider] for key delivery and service notices; Plausible Analytics (EU) for cookieless site statistics.
- No transfers outside the EU. [confirm]
- Access to the ingestion environment and the index is limited to the operator. [confirm; add the actual control if you want to state it]
For your vendor review
- What you send us
- A 6-character hash prefix and an API key. No password, no full hash, no user identifier. See the threat model.
- What we store about you
- Key ID, timestamp, response code and latency per request, rotated. The email on the account.
- What the dataset holds
- Salted password hashes and categories. No identifiers, no source sites.
- Raw material retention
- Deleted within [N] days of arrival, after the password field is extracted.
- Breach notification
- If the index, logs or the ingestion environment are compromised, key holders are notified without undue delay, and within 72 hours where GDPR requires it. [confirm]
- Where it runs
- EU, [provider], operated by KnownPass s.r.o., Czech Republic.
Questions and requests
Anything about the dataset, the sources or this page: privacy@knownpass.com. Security researchers who want to demonstrate an issue with the dataset should use their own test passwords, as described on the security page.