What leaves your server, and what we can learn from it.

What leaves the client

What a prefix tells us

Six hex characters give 16⁶ = 16,777,216 buckets. At 20 billion entries, a bucket averages about 1,200: 20,000,000,000 ÷ 16,777,216 is about 1,192 entries, roughly 80 KB of JSON before compression. A response holds only the entries from the datasets your key includes, so the count you get varies by key and by bucket. From a request we can tell some things and not others:

We can tell

Which bucket was asked for, by which key, when, and how often that key calls us.

We can’t tell

Which of the candidates you were interested in, whether any of them matched, or who the end user is. The comparison never leaves your server.

A prefix on its own does not identify a password. Hundreds of known passwords share each prefix, and so do countless passwords that are on no list at all.

Why the salt is public, and what it does

The salt string Salted for knownpass.com: is fixed and published. It adds no secrecy; its job is domain separation:

• A PasswordRadar prefix can’t be matched directly against Pwned Passwords or any other unsalted SHA-1 dataset. It is not a secret, though: the salt is published, so anyone can compute the salted prefixes of their own guesses. A prefix narrows a password to its bucket and no further.
• An unsalted SHA-1 prefix captured from another service cannot be replayed against PasswordRadar, and vice versa.
• SHA-1 is used as a lookup key over a public dataset, not to protect a stored secret. Your password store should keep using Argon2id, scrypt or bcrypt.

The salt and the API host keep the original name: their domain belongs to KnownPass s.r.o., the company that runs PasswordRadar (formerly knownPass). The salt is part of every hash in the dataset, so it stays exactly as it is, and existing integrations keep working unchanged.

What we log

Per request: key ID, timestamp, response code and latency, for rate limiting, abuse prevention and debugging. Logs rotate; we keep no long-term record of individual requests. Per-key daily request counts are kept for invoicing; they never include prefixes. The API’s web server also keeps a standard access log for at most 15 days: the calling IP address, the time and the request line, which includes the prefix. For a check your server makes, that address is your server’s, not your user’s, so nothing we hold connects a prefix to one of your users; for the demo on our website, it is the visitor’s. The privacy policy is the binding version of this list.

The demo on passwordradar.eu sends nothing when the page loads, and nothing while you type. The first time you use it (you click or tab into its field, press Check or pick a sample), your browser sends one health check, GET /v1/health, with no key and no password data. Each check you run then sends the same six-character prefix, with a public shared demo key. Because that request carries a key, your browser first sends a preflight (OPTIONS) for the same prefix, without the key. That is all: one prefix per check.

Why EU hosting still matters

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.

The same question is answered in the FAQ on hosting location.

If the API is down

Design the check to fail open: on timeout, network error, 429 or 5xx, let the flow continue, log that the check was skipped, and re-check at the next login or password change. A 400, 401 or 403, or any other error (a malformed key, a TLS failure), means something needs fixing: let the flow continue there too, but log it as an error, because nothing is screened until it’s fixed. What’s at risk during an outage is that a weak password slips through until then. Nothing else in your auth flow depends on us. There is no uptime SLA yet; the status page is updated by hand.

Abuse considerations

Reconstructing the dataset

A full crawl means roughly 17 million authenticated requests, each returning hundreds of entries. Each key includes 1,000 requests a day; past that, every request is billed, or refused with 429 on a key without a payment method or prepaid credit. The response carries no counts and no plaintexts, so the result is a list of salted hashes. The base dataset is derived from public material, and every plan, Free included, can already download it in bulk under CC BY-NC 4.0, so we meter crawling rather than treat the list as a secret.

Using the API as an oracle

The API answers “is this password known”, never “does this password belong to user X”. It cannot confirm a credential for a target account. It could help an attacker prune a candidate list, which public wordlists already allow offline; we don’t consider that a meaningful uplift, and per-key metering limits it.

Key leakage

Keys identify a customer account, not an end user. A leaked key lets someone use up the 1,000 requests a day included with your key and, if the key has a payment method or prepaid credit, run up metered requests; it exposes no data about your users. Email hello@passwordradar.eu to rotate it; self-serve rotation is planned for the admin console, which isn’t open yet. The demo key is public by design and throttled.

Network observers

An observer between you and us sees TLS to api.knownpass.com and a response size. At most that narrows the request to a bucket, which is the same thing we see.

What this does not protect against

PasswordRadar is one control. It won’t stop phishing or a targeted guess at a password that is on no list, and it doesn’t replace MFA. It removes the passwords an attacker will try first.