FilterHN

Show HN: Building a future where security checks leave no permanent trails

1 points

1 hour ago

| 2 comments

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 RFC Draft: https://github.com/IAmAxolotl-04/password-smoke-detector/tre...

▲

pkolbus

6 minutes ago

[-]

The 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. 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/

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.

▲

chrisjj

1 hour ago

[-]

Surely 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.