Opt-in breach checks
Proposal, not an available feature. No network permission or new data collection is enabled. These RFCs are locally prepared; remote review/merge awaits the owner repository.
Current architecture
The website currently has connect-src none and no network client for vault data. An ordinary email breach lookup cannot be described as password-style k-anonymity.
Design under review
Keep checks off by default. For a manually selected password check, derive SHA-1 locally only for the Pwned Passwords protocol, send the five-hex prefix after explicit consent, request padded responses, compare suffixes locally and discard them. No per-keystroke calls, full hashes, passwords or email identifiers go with this request. Email alerts require a distinct consent/API/service design and must not be represented as client-only anonymous alerts.
Milestones
- M1: network/privacy RFC and narrow endpoint/CSP design with independent review
- M2: mocked range protocol, zero-count padding, rate-limit and offline tests; manual opt-in UI
- M3: separately reviewed email monitoring service or omit it; publish metadata/retention terms before activation
Required acceptance tests
- Default-off mode produces zero outbound checks
- Only the documented prefix leaves the client after consent
- Failures display Unknown, never Safe; email address is not sent by password checks
Limits
Prefix, IP address and timing are still exposed to the provider. No live API calls or CSP relaxation are part of this proposal.
Any implementation must preserve local unlock/export, add KDBX/KeePassXC regressions for crypto/format changes and update privacy disclosures before new data flows begin.
Primary references: haveibeenpwned.com