A breached-password warning is useful only if the check does not create a new disclosure. Uploading every vault password to a third party would turn a defensive feature into a high-value data transfer. Sending a full unsalted password hash is better than sending plaintext, but it can still reveal the password when an observer tests likely candidates against that exact hash.
There is a practical middle ground. Have I Been Pwned's Pwned Passwords service supports a range-search protocol designed around k-anonymity. The password manager can ask for a group of possible breached hashes, then decide locally whether the exact password is in that group. The service never needs the plaintext password or its complete hash.
Quick answer
Yes. Krypt hashes each complete password locally with SHA-1, splits the uppercase hexadecimal hash after its first five characters, and sends only that five-character prefix to the HIBP Pwned Passwords range endpoint. HIBP returns the suffixes and breach counts for hashes with that prefix. Krypt compares those suffixes with the remaining 35 characters locally and reports a match without uploading the password or full hash.
This is a privacy-preserving lookup, not perfect secrecy. The request reveals a 20-bit hash prefix and therefore the candidate bucket. Krypt's current client does not request HIBP's optional response padding. The Pro scan is on demand rather than continuous, and it is not email-breach or dark-web monitoring. For a prefix request that succeeds, no matching suffix means only “no match in the corpus returned now,” not “this password has never been exposed anywhere.”
What Krypt sends—and what stays local
For each stored password, Krypt computes SHA-1 on the device and converts the 20-byte digest to 40 uppercase hexadecimal characters. Five hexadecimal characters encode 20 bits, so the request identifies one of 1,048,576 possible prefix buckets. The remaining 35 hexadecimal characters stay on the device.
The network request has the form https://api.pwnedpasswords.com/range/ABCDE, where ABCDE is only an example prefix. The response contains lines such as a 35-character suffix followed by the number of appearances in the Pwned Passwords corpus. Krypt reconstructs each returned full hash from the requested prefix and returned suffix, compares that value with hashes already computed locally, and associates any match with the corresponding vault records.
Krypt groups records by prefix before querying. Two different passwords that fall into the same prefix bucket can be checked with one range response, and repeated copies of the same password do not require separate full-password lookups. The comparison and mapping back to account records happen after the response reaches the device.
Why SHA-1 here is not password storage
SHA-1 should not be used as a password-storage function. It is fast, unsalted, and unsuitable for protecting a password database against offline guessing. That warning does not make every SHA-1 use equivalent. HIBP uses SHA-1 as a deterministic index for a corpus of already-compromised password values, and the client needs the same index to request the correct range.
Krypt does not replace its vault encryption with SHA-1. The digest exists to perform this lookup, is split on the device, and is not sent in full. The security question is therefore not “Can SHA-1 safely store my password?”—it cannot—but “Can a partial deterministic identifier retrieve a large candidate set while keeping the exact candidate local?” That is the role of the range protocol.
What k-anonymity protects
If a service received a complete hash, it could compare common passwords against that exact value and often recover the input. With the range API, HIBP sees only the prefix shared by many entries. Its documentation says a typical response now contains roughly 800 suffixes. The server knows that the requested password, if it is represented in the corpus, belongs somewhere in that set; it does not learn which returned suffix Krypt matched.
The protocol also avoids the risky pattern of sending prefixes as a person types. Cloudflare's original implementation discussion warns that successive partial searches can reveal far more than one completed lookup. Krypt hashes complete stored password values during a deliberate health scan. It does not transmit a sequence of changing prefixes from password-entry keystrokes.
What the protocol does not hide
K-anonymity narrows disclosure; it does not eliminate it. HIBP necessarily sees the requested prefix, and a party able to observe that application-level request would know the same candidate bucket. HTTPS protects the request in transit from ordinary network observers, but the endpoint still receives the prefix. A targeted attacker who already has a short list of likely passwords could hash those guesses and determine which ones share that prefix.
HIBP offers an optional Add-Padding: true request header. It adds randomly generated zero-count suffixes so response sizes are less revealing. Krypt's current client makes the range request without that header, so the article cannot claim padded responses. Adding padding would be defense in depth; it would not change the core rule that only the prefix is requested and the suffix match remains local.
The query also does not say where a password appeared. Pwned Passwords is a password-hash corpus, not an account-attribution service. Krypt does not send an email address in this flow, identify a breached website from the hash match, or claim to search every private criminal forum. The breach count describes appearances in the available corpus and should be treated as a rotation signal, not a forensic timeline.
Local password-health analysis is a separate layer
Krypt can flag weak, reused, and old passwords without making a HIBP request. Reuse is determined by grouping equal password values from the locally decrypted records. The current weak-password rule flags an empty password or one shorter than eight characters. “Old” means the record's last update is more than 365 days ago. Those rules run against data already available to the app.
These are useful inventory signals, not a complete strength proof. A nine-character dictionary word can evade a length-only weak flag. A strong password does not become compromised merely because it is old, while a newly created reused password can still enable credential stuffing. NIST's current guidance emphasizes comparing prospective passwords against a blocklist of common, expected, or compromised values and allowing password managers; it does not support arbitrary periodic changes as a substitute for evidence of compromise.
The network-backed compromised-password scan is different. It is a Pro action the user starts from Password Health; it is not a background monitor promising immediate future alerts. The screen records when the user ran the check and writes returned exposure counts to password records. However, an individual prefix request that fails is ignored by the service, and the screen defaults a missing result to zero. Run the scan again after an incident, after importing older credentials, or whenever connectivity or service availability was uncertain.
How to interpret a match—or no match
A match is decisive enough for action: the password value appears in the Pwned Passwords corpus. Change it everywhere it was reused, beginning with email, financial, cloud, domain, and identity-provider accounts. Generate a unique replacement, enable phishing-resistant MFA where supported, and check recent sessions and recovery settings. Do not merely append a character to the exposed password.
A non-match is narrower. For a prefix that returned successfully, it means no returned suffix matched. A breach may not yet be discovered or published, may be absent from HIBP, or may happen tomorrow. There is also a current implementation limit: if an individual prefix request fails, Krypt ignores that failure, defaults affected records to zero, records the scan time, and may still show “No new breaches found.” An apparently clean result can therefore be incomplete. Retry before relying on it whenever the connection or service may have failed.
The check also cannot determine whether an account is currently controlled by an attacker. Security alerts, unknown sessions, changed recovery details, unexpected MFA prompts, and provider breach notices require their own response even when the stored password has no corpus match.
Krypt's answer: private breach checks with explicit limits
Krypt combines a local vault-health inventory with an on-demand range search. The Password Health Check groups reused passwords, applies the current weak and age rules locally, and lets Pro users request a HIBP comparison without sending complete password values or complete SHA-1 hashes.
That makes Krypt a practical zero-knowledge password manager for people who want breach evidence without pretending the lookup is invisible. The honest boundary matters: the prefix leaves the device, current responses are not padded, checks are not continuous, and the result covers HIBP's present corpus rather than every possible exposure.
Practical breached-password checklist
- Run the compromised-password scan from a trusted network and retry if connectivity is interrupted.
- Treat every match as compromised, even when the returned count is low or the account has MFA.
- Use the reuse view to find every record containing the same password, not only the first account shown.
- Change the primary email and identity-provider credentials first because they can reset other accounts.
- Generate a unique random replacement instead of making a predictable variation of the breached password.
- Review active sessions, forwarding rules, recovery methods, app passwords, and connected applications.
- Enable a passkey or hardware security key where available, then safely retain backup recovery methods.
- Re-run the health scan after major breach notices, credential imports, or suspicious account activity.
- Remember that “not found” is a point-in-time corpus result, not a certificate that the secret is safe forever.
FAQ
Does Krypt send my full password or full SHA-1 hash to HIBP?
No. Krypt hashes the complete password locally with SHA-1, sends only the first five hexadecimal characters to the HIBP Pwned Passwords range endpoint, and compares returned hash suffixes with the remaining local hash. The full password and full hash are not sent by this check.
Does a clean breached-password check prove my password has never leaked?
No. Krypt currently treats a failed individual prefix request like no match for that group and can still record the scan and show a no-new-breaches message, so an apparently clean result may be incomplete. Even when every request succeeds, a breach may be unknown, unpublished, absent from HIBP, or added later. Retry whenever connectivity or service availability was uncertain.
Is Krypt's password-health scan the same as email or dark-web monitoring?
No. Krypt checks stored password values against the Pwned Passwords hash corpus and separately analyzes weak, reused, and old passwords locally. It does not search an email address, identify which account breach exposed a password, or continuously monitor dark-web sources.
Technical references
The official HIBP Pwned Passwords API documentation specifies the five-character SHA-1 range request, returned suffixes and counts, response padding, and incremental-search warning. NIST SP 800-63B password-verifier requirements cover compromised-password blocklists, password-manager support, and password-change policy. Cloudflare's original k-anonymity implementation explanation documents the five-hex-character bucket design and its privacy tradeoff.
Use Krypt to review weak, reused, old, and known-compromised passwords while keeping full password values out of the HIBP request.
