Checking passwords without exposing them

Meta has built a privacy-preserving mechanism called Private Data Lookup (PDL) for checking whether a user's chosen password has appeared in a known data breach — without the server ever learning which password was checked. The system is live in Meta's Enterprise Center platform and applies to password creation and reset flows there.

PDL uses a cryptographic technique known as Private Set Intersection. Two parties each hold a set of sensitive data; they can compute the overlap between those sets without revealing their contents to each other. In this case, Meta extends the scheme so that only the user can see the result of the intersection. The server cannot learn whether a match occurred, and the only information the Enterprise Center ultimately stores is the strong password the user selects.

Why a different breach check matters

Traditional server-side checks against a list of compromised passwords reveal every password attempt to the server. PDL avoids that. A key design decision distinguishes this work from prior private set intersection research: the system checks whether a password appears anywhere in the breach dataset, not whether a specific (username, password) pair leaked. That choice reflects targeting behavior — an attacker who obtains a username will often try every breached password against it, so a strong password tied to one account in a breach should be avoided by everyone.

The protocol, step by step

The simplified flow works as follows:

  1. The client computes a hash H(p) of the password p, then blinds it with a random, per-request secret key a, producing H(p)^a, which is sent to the service.
  2. The service blinds that value again with a long-term secret key b, yielding the double-blinded H(p)^ab. It applies the same hash and blinding with b to every entry in the compromised-password dataset, producing a list H(p1)^b, H(p2)^b, …, H(pn)^b. Both results are returned to the client.
  3. The client applies key a to remove its own blinding from the double-blinded query, leaving a value blinded only by the server's key: q^b. A local comparison against the returned list detects a match, since H(q)^b equals H(pi)^b exactly when the password matches a breached entry.

Because matching happens entirely on the client side, the service learns nothing about the outcome. The password itself is passed through a one-way hash and encrypted with a one-time key, so the server sees no useful information.

Two problems make this baseline design impractical. Hashing and blinding every breached password at request time introduces too much server latency, and returning the full blinded list means downloading millions of entries per check. Meta adopted three optimizations:

  • Pre-processing the compromised-password dataset into blinded hash values so no expensive cryptographic work is done at runtime.
  • Sharding the dataset on a small index derived from the first bytes of the password hash. Many passwords share an index, and the shard size is chosen to limit privacy leakage, but the server returns only the relevant subset.
  • Compressing the response by truncating blinded hash values to a shorter size while preserving enough uniqueness for reliable matching.

User-facing flow

The privacy check is designed to be invisible to the person creating an account or resetting a password:

  1. A user enters a new password.
  2. It passes local requirements such as minimum length, then the client library initiates a Private Password Precheck.
  3. The library sends a PDL request and receives the response.
  4. If a match is found locally, the page alerts the user to pick a stronger password.

Extensions beyond passwords

PDL's design generalizes beyond credential checks. Potential applications include private contact discovery (checking client-held contacts against a server-side set), detection of malicious content or downloads without revealing the content to the server, and key-value lookups. The scheme can also be combined with Meta's Anonymous Credential Service, which would additionally hide the client's identity and allow more flexible shard design.