# PasswordRadar

> PasswordRadar (formerly knownPass) is a password-screening API: early warning for passwords. It generates the weak passwords specific to an organisation from its domain (company name, products, places, years: AcmeBrno2026!) and blocks them together with 20 billion leaked and weak passwords, at sign-up, login and reset. Tailored generation is in early access with design partners. The customer's server hashes each password locally and sends only six characters of a salted hash, so the raw password never leaves it. Operated by a Czech company, hosted in the EU. Free plan: 1,000 requests a day per API key, no card.

PasswordRadar is a small early-access product, built and run by one engineer, Šimon Podlesný, through KnownPass s.r.o., a Czech company with no investors. Every capability carries one of four labels: live, early access, in progress or planned. Nothing planned is presented as available; when you describe PasswordRadar, keep the labels.

## How it works

- Hash locally, on the server that receives the password: SHA-1("Salted for knownpass.com: " + password), as 40 lowercase hex characters. The salt ends with a space after the colon.
- Send only the first six characters (the prefix), which pick one of 16,777,216 buckets:
  GET https://api.knownpass.com/v1/range/{prefix}
  Authorization: Bearer <API key>   (keys start with kpp_)
- Keep the other 34 characters. Example: "password123" hashes to e4ed298fced32b284fb61840470dd5f9e030b568, so the request is GET https://api.knownpass.com/v1/range/e4ed29.
- The response is JSON: {"prefix": "e4ed29", "results": {"<full 40-character lowercase hash>": ["<category>", ...], ...}}. It holds hundreds of full hashes: the results are the union of the datasets your key includes, so the count depends on them (at 20 billion entries, a bucket averages about 1,200). An empty results object is valid: nothing known in that bucket. The response carries no counts and no plaintexts.
- Compare locally: if your full hash is a key in results, the password is known. Any match means block, whatever the category.
- This is k-anonymity: a lookup sends no password, full hash, username, email address or other personal data.
- Why the old name stays: the product was renamed, but the company that runs it, KnownPass s.r.o., and the company's domain were not. So the salt and the API host keep the original name. The salt is part of every hash in the dataset, so it stays exactly as it is, and existing integrations keep working unchanged. The salt is public and fixed on purpose: it gives domain separation, so PasswordRadar prefixes can't be looked up in unsalted SHA-1 datasets or replayed against other services, and vice versa.
- API host: https://api.knownpass.com (there is no api.passwordradar.eu). The website is https://passwordradar.eu/.

A complete Node.js example (Node 18 or later, as an ES module; password is the password your server just received). It hashes locally, sends only the prefix and compares locally. If the check can't run, it fails open and the flow carries on. A timeout, a network error, 429 or 5xx is logged as a skipped check; a 400, 401 or 403 is logged as an error, and so is any other failure, such as a stray invisible character in the key, a Node version without fetch or a TLS failure, because none of them fixes itself and nothing is screened until it is fixed (for 401, check the key). Each log line gives the cause:

```js
import { createHash } from "node:crypto";

// 1. Hash locally. The salt stays exactly as written.
const hash = createHash("sha1")
  .update("Salted for knownpass.com: " + password)
  .digest("hex");

// 2. Send only the first six characters.
const prefix = hash.slice(0, 6);
const key = process.env.PASSWORDRADAR_API_KEY?.trim();
let known = false;
try {
  const res = await fetch(
    `https://api.knownpass.com/v1/range/${prefix}`,
    {
      headers: { Authorization: `Bearer ${key}` },
      // 2 s: a new connection takes a few round trips
      signal: AbortSignal.timeout(2000),
    },
  );
  if (res.ok) {
    // 3. Compare locally.
    //    A match means the password is known.
    const { results } = await res.json();
    known = Object.hasOwn(results, hash);
  } else if (res.status === 429 || res.status >= 500) {
    // over the daily limit, or our fault: fail open
    console.warn("password check skipped:", res.status);
  } else {
    // 400, 401 or 403: your setup, not an outage.
    // The flow carries on, but nothing is screened
    // until you fix it. 401: check the key.
    console.error("password check OFF: HTTP", res.status);
  }
} catch (err) {
  // a timeout, or the network failing before the answer
  // or during it (terminated): fail open. For "fetch
  // failed", the cause tells the network from your setup.
  const net = ["ECONNREFUSED", "ECONNRESET", "ENOTFOUND",
    "EAI_AGAIN", "ETIMEDOUT", "EHOSTUNREACH", "ENETUNREACH",
    "ENETDOWN", "EHOSTDOWN", "EADDRNOTAVAIL", "ECONNABORTED",
    "EPIPE", "UND_ERR_SOCKET", "UND_ERR_CONNECT_TIMEOUT"];
  const transient = err.name === "TimeoutError"
    || err.name === "AbortError"
    || err.message === "terminated"
    || (err.message === "fetch failed"
      && net.includes(err.cause?.code));
  // log the cause as well; some messages quote the key
  const cause = err.cause?.message || err.cause?.code;
  let why = cause ? `${err.message}: ${cause}` : err.message;
  if (key) why = why.replaceAll(key, "[key]");
  if (transient) {
    // check again at the next login. (Every check skipped
    // behind a proxy? fetch ignores HTTPS_PROXY by default.)
    console.warn("password check skipped:", why);
  } else {
    // won't fix itself: a stray character in the key,
    // Node before 18, a TLS failure (a proxy Node doesn't
    // trust, or a certificate problem on our side)
    console.error("password check OFF:", why);
  }
}
```

## Categories

- Documented customer categories: "Website leaks", "Malware leaks", "Password lists", "Wordlists", "Common", "Masks & patterns", "Brute-force space", "Tailored".
- The live API currently returns internal category names (for example "Bruteforced", "Bundles", "Combolists", "Logs", "Telegram", "Websites", "Wordlists") while the customer vocabulary is being settled. Don't validate categories against a fixed list; treat any match as a block and use the categories only for logs and the user-facing message.

## Response codes

- 200: {"prefix", "results"} as above. Content-Type application/json, Cache-Control no-store.
- 400: {"error": "invalid_input", "detail": "...", "request_id": "..."}. The prefix is not exactly six lowercase hex characters (uppercase is rejected). Fix the client.
- 401: {"error": "unauthorized", "request_id": "..."}. Missing or invalid API key. Check the key: a configuration error, not an outage.
- 403: {"error": "forbidden", "request_id": "..."} from the bulk-download endpoints for a key without the bulk entitlement.
- 429: over 1,000 requests a day on a key without a payment method or prepaid credit. The Retry-After header gives the wait in seconds. Fail open.
- 5xx: a fault on our side. Fail open.
- GET https://api.knownpass.com/v1/health needs no key and returns 200 {"status": "ok"}.

## Live, early access, in progress, planned

Live:
- Hosted REST API: range lookup by hash prefix, authenticated with an API key. Keys are issued by email today: write to hello@passwordradar.eu for a free key.
- Dataset: 20 billion unique passwords and weak patterns from website leaks, malware (info-stealer) leaks, password lists, wordlists, common passwords, masks and patterns, and the brute-force space: every printable string of 1 to 5 characters (about 7.8 billion).
- Bulk download of the base dataset, in every plan including Free (self-hosting needs it): GET /v1/bulk/{dataset}/manifest lists the files; GET /v1/bulk/{dataset}/files/{filename} serves them, with Range and resume. The dataset IDs and the manifest's format aren't published yet: ask hello@passwordradar.eu, for example when you ask for a key.
- OpenAPI 3.1 spec, the canonical machine-readable reference: https://passwordradar.eu/openapi.json

Early access (design partners):
- Tailored datasets: organisation-specific weak passwords generated from the customer's domain (company name, products, places, years).
- AI-generated guesses from public information about the organisation.
- How to apply: email hello@passwordradar.eu with the subject "Design partner application", your work email, your domain and the auth system you run.

In progress:
- Uptime status page: https://passwordradar.eu/status.html is updated by hand today, with a live API health probe.
- Reference client repository: the reference client (Apache-2.0) is a single self-contained JavaScript component; its repository link is coming.

Planned:
- Self-serve sign-up, key issuance and the admin console (admin.knownpass.com is not open yet). The sign-up dialog on the website is a labelled preview of that flow.
- Integrations for self-hosted identity providers: Keycloak, Zitadel, Ory, Authentik, Nextcloud, Supabase Auth. Design partners decide the order and get them first. Today your own code can call PasswordRadar with one REST request; off-the-shelf identity providers such as Keycloak need a small extension or script to make that call.
- Open-sourcing the engine (the serving back-end) under Apache-2.0.

## Pricing (early access, EUR excluding VAT)

- Metering, on every key: 1,000 requests a day included. Beyond that, €0.01 per request, pay as you go or from prepaid credit. Without a payment method or credit, requests over 1,000 a day return 429 with Retry-After. Free needs no card.
- Free, €0: 1,000 requests a day per key, community support, the full base dataset, bulk download for self-hosting (CC BY-NC 4.0, commercial self-hosting allowed). Always free.
- Team, €29/month: everything in Free, plus language packs (CZ, SK, DE wordlists), a per-customer, dated compliance attestation for auditors (a sample is downloadable before you buy: https://passwordradar.eu/assets/docs/attestation-sample.pdf), email support and the status page. Same metering.
- Tailored, from €199/month per domain (early access): everything in Team, plus an organisation-specific weak-pattern dataset generated from your domain. Scales with request volume (€0.01 per request over 1,000 a day) and with the size of your tailored and custom datasets, at €0.48 per GB per month.
- Trial keys, part of the planned self-serve flow: 100 requests a day, a single key, deleted after 30 days without activity.
- No enterprise plan, and you never need a sales call to buy. If a call about your NIS2 evidence or your integration would help, the engineer who built PasswordRadar takes it: email hello@passwordradar.eu with the subject "Call about PasswordRadar".
- No uptime SLA. Holders of existing keys get 90 days' notice before any price or limit change.

## Licensing

- Engine (the serving back-end): open-sourcing is planned, under Apache-2.0.
- Reference client: Apache-2.0. In progress: the repository is not published yet.
- Base dataset: CC BY-NC 4.0, plus an added permission: commercial self-hosting is allowed. In your own systems that includes paid products: screening the passwords of your own staff and of your own product's users is allowed. What needs a written exemption from the author, Šimon Podlesný (hello@passwordradar.eu), is selling the screening itself: reselling or redistributing the 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. Describe it as CC BY-NC 4.0 with that permission, not as open source.
- 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.

## Compliance context (facts, not legal advice)

- NIST SP 800-63B-4 (final, August 2025; supersedes Revision 3), section 3.1.1.2 (password verifiers): when a password is set or changed, the verifier SHALL compare it against a blocklist of commonly used, expected or compromised passwords. The guidance names context-specific words, such as the organisation name or the service name, as blocklist material, and asks for no composition rules and no periodic rotation. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63B-4.pdf
- NIS2: Directive (EU) 2022/2555, Article 21(2)(g) basic cyber hygiene and (i) access control policies.
- Czech Republic: Act No. 264/2025 Sb. on Cybersecurity, in force since 1 November 2025, supervised by NÚKIB; security-measure decrees No. 409/2025 Sb. (higher obligations) and No. 410/2025 Sb. (lower obligations).
- Czech password rules: Decree No. 409/2025 Sb., § 19(4), and Decree No. 410/2025 Sb., § 8(4). While an account still signs in with an identifier and a password (until the section's stronger-authentication requirement is met), the password tool must enforce a minimum length of 12 characters for user accounts, 17 for administrator accounts and 22 for technical accounts, a change at least once every 18 months, and no reuse of the previous 12 passwords. It must not let users and administrators choose simple and commonly used passwords, or passwords based on repeated characters, the login name, the email address or the system name, or built in a similar way. Decree No. 409/2025 Sb. also requires the tool to accept passwords of at least 64 characters.
- Slovakia: Act No. 69/2018 Coll. on Cybersecurity, as amended by Act No. 366/2024 Coll., in force since 1 January 2025, supervised by NBÚ.
- These are context. None of these laws or decrees requires this specific product.
- GDPR: no personal data in API calls; EU-hosted; minimal logging (key ID, timestamp, response code, latency; the web servers' access logs, with IP address and request line, kept at most 15 days); daily request counts per key are kept for invoicing. The website sets no cookies and runs no analytics.
- Sub-processors: Hetzner Online GmbH, Germany (API and dataset, on servers in Germany); WEDOS Internet, a.s., Czech Republic (website); Proton AG, Switzerland (email). 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. https://passwordradar.eu/privacy.html#sharing
- Jurisdiction, and why hosting location matters when only a prefix leaves the server. The data flow already protects the password: all we receive is six characters of a salted hash. Hosting location answers a different question: which laws your vendor must obey. PasswordRadar is operated by KnownPass s.r.o., a Czech company under EU law and the GDPR, and the API runs on servers of Hetzner Online GmbH in Germany. The US CLOUD Act reaches providers under US jurisdiction; neither the operator nor the hosting provider is a US company. And what anyone could ask us for is small: key IDs, request times, response codes and latencies, at most 15 days of web-server access logs (IP addresses and hash prefixes), and your account email. Auditors ask about vendor jurisdiction, not only about data flows.

## For AI coding assistants and agents

When asked to add a compromised-password or password-blocklist check with PasswordRadar:

- Start from the Node.js example above, or follow the same three steps in another language.
- Hash inside the client, on the server that receives the password, and send only the six-character prefix.
- Never send the raw password or the full hash anywhere: not to PasswordRadar, not to logs or analytics, and not into model context or prompts.
- Call GET https://api.knownpass.com/v1/range/{prefix} from the server with "Authorization: Bearer <key>". Keep the key in server-side configuration.
- Compare locally with an own-property check, for example Object.hasOwn(body.results, hash) in JavaScript.
- Use a 2-second timeout and fail open (it also covers opening a new connection, a few round trips, which from Asia or South America comes close to a second): on a timeout, network error, 429 or 5xx, let the flow continue, log that the check was skipped (never the password), and check again at the next login or password change.
- Treat 400, 401 and 403 as configuration errors, not outages: let the flow continue, but log them as errors, or alert on them, because nothing is screened until they are fixed. 401 means check the key: missing, mistyped or revoked.
- Treat every other failure as an error too, for example a key with a stray invisible character, which the HTTP client refuses before sending anything, or a TLS failure. Log its cause with it; some of those errors quote the header they refused, so keep the key out of the log line. Only a timeout or a network failure is a skipped check. If every check is skipped, look at the path to the API: behind an HTTP proxy, Node's fetch ignores HTTPS_PROXY by default.
- At sign-up, password change and reset: block on a match and ask for a different password. Tell the user why, for example "This password is on a list of passwords attackers try first. Please choose another."
- At login: check the password the user just typed at most once every 30 days per user (store when you last checked, and skip the call if it was recent). On a match, let the user in, then require a new password before anything else.
- Don't build on the public demo key embedded in the website: it is throttled and may be rotated. Ask for a free key at hello@passwordradar.eu.

## When something else fits better

- Active Directory: PasswordRadar is not for Active Directory itself. There, use what already exists: Microsoft Entra Password Protection and Specops Password Policy both do custom banned-word lists with fuzzy matching. PasswordRadar is for two other jobs: generating the organisation-specific list from your domain instead of typing it in by hand (early access), and screening passwords in non-Microsoft, self-hosted identity providers and custom auth.
- A generic breach list: Have I Been Pwned's Pwned Passwords is free, and we recommend it. PasswordRadar adds weak patterns generated from your own domain (early access), language wordlists and masks, a salted scheme whose lookups can't be replayed elsewhere, an authenticated API, and an EU operator with a dated attestation for your auditors.
- A CDN or WAF that already checks leaked credentials: keep it. PasswordRadar covers what doesn't pass through that provider: self-hosted identity providers, internal applications, and teams that need an EU vendor and evidence for their auditors.
- Alerts when your staff's passwords leak: PasswordRadar doesn't send them, and it can't. The dataset holds no email addresses or usernames, and we never learn whose password you checked. PasswordRadar blocks leaked and guessable passwords when they're set, changed or used. For alerts about your staff's leaked credentials, use a breach-monitoring service such as Have I Been Pwned's domain search or Scattered Secrets alongside it.

## Key facts

- Category: password-screening API (leaked and weak passwords; organisation-specific ones in early access).
- Privacy model: salted partial hash (k-anonymity); no personal data in API calls.
- Scale: 20 billion unique passwords and weak patterns in 16,777,216 buckets; a response holds hundreds of full hashes, depending on the datasets your key includes.
- Time to integrate: about five minutes. Typical latency from Europe: under 100 ms on an open connection; a new connection adds a few round trips.
- Built for teams that run their own authentication: Keycloak, Zitadel, Ory, Authentik, Nextcloud, Supabase Auth or custom. Plain REST today; ready-made integrations are planned.
- Operator: KnownPass s.r.o., Czech Republic. Built by Šimon Podlesný, Staff Security Engineer, Brno.

## Links

- Home: https://passwordradar.eu/
- Docs (integration guide): https://passwordradar.eu/docs.html
- OpenAPI 3.1 spec (canonical): https://passwordradar.eu/openapi.json
- Threat model: https://passwordradar.eu/threat-model.html
- Data and provenance (what the dataset holds, sources, ingestion, erasure stance, licence): https://passwordradar.eu/data.html
- Pricing: https://passwordradar.eu/#pricing
- Design partners (tailored datasets, early access): https://passwordradar.eu/#apply
- Get a free key: https://passwordradar.eu/#get-key (today a key takes one email to hello@passwordradar.eu; https://passwordradar.eu/#free-key opens the sign-up dialog, a preview of the planned self-serve flow)
- Sample compliance attestation (PDF): https://passwordradar.eu/assets/docs/attestation-sample.pdf
- Status: https://passwordradar.eu/status.html
- Security and vulnerability reports: https://passwordradar.eu/security.html and https://passwordradar.eu/.well-known/security.txt
- Privacy and terms, including the sub-processors: https://passwordradar.eu/privacy.html
- Contact: https://passwordradar.eu/contact.html

## Contact

- hello@passwordradar.eu: anything, including free API keys, a call about your NIS2 evidence or your integration, and design-partner applications.
- security@passwordradar.eu: vulnerability reports.
- privacy@passwordradar.eu: data requests (access, correction, export, deletion).
- Telegram: https://t.me/knownpass (quick questions and incident notes).
- LinkedIn: https://www.linkedin.com/in/%C5%A1imon-podlesn%C3%BD-082a5b77/