Show HN: Building a future where security checks leave no permanent trails
1 pointby csp_dev17 days ago4 comments
  • pkolbus17 days 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.

    • 16 days ago
      undefined
  • csp_dev16 days ago
    You’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_dev16 days ago
    My 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?
  • chrisjj17 days 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.
    • csp_dev16 days ago
      You’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.