Data and provenance: what the dataset holds

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. The salt names the project’s original domain (PasswordRadar was called knownPass) and is part of every hash, so it stays exactly as it is.
Categories	Yes. Where the password was seen, or how it was generated: website leaks, malware leaks, password lists, wordlists, common, masks & patterns, brute-force space, tailored. What each one means.
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.

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.

What each category means

Every entry carries one or more categories. In the material column, leaked means passwords real people used, taken from material that already circulates publicly; generated means candidates produced from patterns or from public information; dictionary means words from published dictionaries and wordlists.

Category	Material	Status	What it is
Website leaks	Leaked	live	Passwords from site breaches that already circulate publicly, hundreds of thousands of them, so a password that leaked in any of them is caught here.
Malware leaks	Leaked	live	Info-stealer logs that already circulate publicly, reduced to the password field at ingestion. Identifiers are discarded.
Password lists	Leaked	live	The password lists attackers actually load into their cracking rigs.
Wordlists	Dictionary	live	Dictionary words, including language-specific ones: a word in your users’ language is blocked even when it passes the length check. The CZ, SK and DE language packs come with Team.
Common	Leaked	live	The most-used and most-leaked passwords from the internet’s best-known lists.
Masks & patterns	Generated	live	Predictable structures, such as a word followed by a year and a symbol.
Brute-force space	Generated	live	Every printable string of 1 to 5 characters (about 7.8 billion), pre-generated: the short passwords a brute-force attack tries first.
Tailored	Generated	early access	Weak patterns generated from public information about one customer’s organisation: company name, products, places, years (`AcmeBrno2026!`). Kept per account.
AI-generated	Generated	early access	Guesses a language model makes from public information about your organisation, before an attacker’s model does.

No per-category counts yet. 20 billion is the total of unique entries across all categories, generated patterns included. A password can carry several categories, so per-category counts will overlap rather than add up to the total. They will be added to this page once the export pipeline reports them.

The live API currently returns internal category names instead of these labels, while the customer-facing vocabulary is being settled; the docs say what to expect.

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 printable string of 1 to 5 characters (about 7.8 billion)
Tailored patterns generated from public information about a customer’s organisation, at that customer’s request

We refuse

Paying for data, in any form
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.
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. To stop users choosing their own email address as a password, compare the two on your server; that needs no API call.
What remains is hashed with the public salt and tagged with a category.
The raw file is deleted after processing.
The index receives hashes and tags. Nothing else exists to receive.

Raw material contains personal data from the moment it lands (step 1) until it is deleted (step 5). That window is the only time the dataset pipeline 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). Article 11(2) makes one exception: a person may offer extra information that identifies them in the data. A password can’t do that: the same password belongs to everyone who chose it. 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@passwordradar.eu handles it.

The legal basis, in one paragraph

The ingestion step touches raw material that contains personal data, from its arrival until its deletion. 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-4, section 3.1.1.2), 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 being prepared. This page describes practice; it is not legal advice.

Tailored datasets

early access

A tailored dataset is generated from public information about your organisation (your domain, names, products, places, years) and from anything you choose to add. It is stored per account, never merged into the shared index, and deleted after the account closes or on request. It contains generated candidates, not your users’ passwords; we never see those.

Design partners get tailored datasets first. Apply as a design partner.

Licence

Base dataset: CC BY-NC 4.0 (opens in a new tab)
Plus an added permission: commercial self-hosting is allowed. In your own systems, paid products included, you may screen the passwords of your own staff and of your own product’s users.
Reselling and redistribution: What needs a written exemption from the author, Šimon Podlesný, is selling the screening itself: reselling or redistributing the base dataset, running it for other organisations (for example as a managed service provider or an identity-hosting provider), or making it a paid feature of a security product. Ask at hello@passwordradar.eu.
Tailored and curated datasets: Commercial, for paying customers.
Exit guarantee: If PasswordRadar ever shuts down, customers can download every dataset they are entitled to, free or paid, and keep self-hosting it forever.
Reference client: in progress
Licensed Apache-2.0. The repository isn’t published yet; its link is coming.
Engine: planned
The serving back-end. Open-sourcing it under Apache-2.0 is planned.

Hosting and processors

PasswordRadar is operated by KnownPass s.r.o., Czech Republic. These companies process data for it:

API and dataset: Hetzner Online GmbH, Germany, on servers in Germany.
Website: WEDOS Internet, a.s., Czech Republic.
Email: Proton AG, Switzerland: the operator’s mail, including key delivery and service notices.

Personal data stays in the EU, except email, which Proton AG handles in Switzerland, a country the European Commission recognises as providing adequate data protection. The website runs no analytics. Access to the ingestion environment and the index is limited to the operator.

For your vendor review

What you send us: A six-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, in logs that rotate; no long-term record of individual requests. The web servers’ access logs (IP address, time, request line with the prefix, referrer, user agent), deleted within 15 days. Per-key daily request counts, kept for invoicing; they never include prefixes. The email on the account.
What the dataset holds: Salted password hashes and categories. No identifiers, no source sites.
Raw material retention: Deleted after processing, once the password field is extracted.
Breach notification: If the index, logs or the ingestion environment are compromised, key holders are notified without undue delay. Where GDPR requires it, the supervisory authority is notified within 72 hours.
Where it runs: On servers of Hetzner Online GmbH in Germany, operated by KnownPass s.r.o., Czech Republic. Sub-processors are listed under Hosting and processors.
Licence: Base dataset CC BY-NC 4.0, commercial self-hosting allowed. See Licence above.
Evidence for auditors: The Team plan includes a per-customer, dated compliance attestation for your auditors. See a sample attestation (PDF).

Questions and requests

Anything about the dataset, the sources or this page: privacy@passwordradar.eu. Security researchers who want to demonstrate an issue with the dataset should use their own test passwords, as described on the security page.