3 ms·
Show HN: Building a future where security checks leave no permanent trails
Every time someone checks if a password has been breached, a permanent record is created: this person checked this password at this time.
(All code is open-source, MIT licensed)
I've been exploring whether we can design a different future—one where security doesn't require this privacy trade-off. The Credential Shield Protocol (CSP) is a step in that direction: it allows checking password breaches without the checking service learning whether your password was actually found.
The key insight: send only a fragment (prefix) of the password hash. The server returns possible matches from breach databases, but the actual verification happens on your device. The server is intentionally kept "blind."
What's available today:
• RFC-style draft with formal analysis
• Complete reference implementation (Node.js)
• Test vectors and collision probability analysis
This is early-stage protocol research, not a product. I'm looking for:
- Cryptographic review of the approach
- Feedback on the threat model
- Implementation critique
- Discussion on whether this future is worth building toward
GitHub: https://github.com/IAmAxolotl-04/password-smoke-detector https://github.com/IAmAxolotl-04/password-smoke-detector
RFC Draft: https://github.com/IAmAxolotl-04/password-smoke-detector/tree/main/docs/rfc https://github.com/IAmAxolotl-04/password-smoke-detector/tre...
- chrisjj 10mo agoSurely this is just a data compression exercise - proved by the fact that where the database is small enough to be downloaded and stored locally, the vulnerability need not exist.
- csp_dev 10mo agoYou’ve summed it up perfectly. This is fundamentally about the trade-off between total privacy (local DB) and practicality (server query). The protocol exists only if that middle ground has real users. The compelling case might not be for individuals, but for organizations that must prove due diligence in password screening for compliance like for example, ISO 27001, but want to minimize their own liability and logging footprint.
- pkolbus 10mo agoThe concept of sending a hash prefix is exactly what haveibeenpwned.com uses for its Pwned Passwords API, and has used for years. Although that uses SHA-1, no other details of the credential are sent. https://haveibeenpwned.com/API/v3#PwnedPasswords https://haveibeenpwned.com/API/v3#PwnedPasswords. The shorter prefix length increases the size of the response and makes it harder for the server to infer which of the hashes is of interest to the client; it also facilitates caching. There is also Password Set Intersection with Blinding, which takes advantage of homomorphic encryption: https://openmined.org/blog/private-set-intersection/ https://openmined.org/blog/private-set-intersection/ Neither of these leave the record that a particular password was checked at a particular time. I’d also argue that anything requiring a server query leaves some record and is not “100% local”, although some server interaction is pragmatic given the billions of breach records. What is important is to not leave additional record of a user/password association.
- deleted 10mo ago[deleted]
- csp_dev 10mo agoYou’ve summed it up perfectly. This is fundamentally about the trade-off between total privacy (local DB) and practicality (server query). The protocol exists only if that middle ground has real users. The compelling case might not be for individuals, but for organizations that must prove due diligence in password screening for compliance like for example, ISO 27001 but want to minimize their own liability and logging footprint.
- csp_dev 10mo agoMy open question to you both and others is this: In your view, is that "organizational compliance with minimal logging" use case substantial enough to warrant a new, standardized protocol? Or is it adequately served by either a) mandating HIBP's API, or b) telling companies to download and manage the full HIBP dataset locally? What's the approach from a consumer standpoint?