SaaSAuthentication

Password Screening

Reject passwords already circulating in breach dumps at the moment of registration.

Password breaches · 1 credit per lookup · no monthly fee

Choose password

••••••••••
Found in 3 breaches — choose another

The problem

Users pick passwords that are already in attacker wordlists, 'password123' has been breached fifty million times and someone will try it on your signup form today. Accepting a known-breached password is pre-approving the account takeover.

With Encrata

Screen at registration with a single call. SHA-1 the password client-side, send the hash, and get back whether it's breached and how many times. Rejecting a password seen 52 million times isn't paranoia, it's the NIST-recommended baseline, implemented in an afternoon.

How it works

1

Hash locally

Your client hashes the password and sends only the first characters of the hash, the password itself never leaves the device.

2

We match anonymously

Encrata checks the prefix against the breach corpus via k-anonymity and returns whether the password was found and how many times.

3

Reject or accept

Block passwords that appear in breach dumps at registration, reset or login. One credit per check.

One call, structured answer

Password Screening runs on the password breaches lookup at 1 credit per lookup. Same API key, same JSON shape as every other Encrata lookup.

  • k-anonymity: the password never leaves the user's device
  • Blocks the exact credentials attackers use in stuffing lists
  • 1 credit per check, screen every registration and reset
  • A single API call satisfies auditors asking for compromised-password controls
Terminal
curl -X POST "https://encrata.com/api/agent/password-breaches" \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{"sha1": "5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8"}'
response.json
{
"prefix": "5BAA6",
"found": true,
"count": 52372427,
"credits": 1
}

Hash on the client, reject early

Hash client-side and send only the SHA-1, the plaintext never leaves the browser. On a found result, reject with a message that blames the breach corpus, not the user: 'this password appears in known data leaks' converts to a changed password; 'password too weak' converts to password123 with an exclamation mark.

Stuffing fails preemptively

Screening at the front door is the single highest-leverage credential control: every rejected breached password is a stuffing attack that fails preemptively. NIST 800-63B explicitly recommends checking against known-compromised corpora, so the same afternoon of integration work also closes a line item in your next security review.

More password breaches use cases

View all
Start with 500 free credits
$curl https://encrata.com/api/agent/lookup -H "Authorization: Bearer YOUR_API_KEY" -d '{"e": "satya@microsoft.com"}'