BankingSecurity

Reset Screening

Stop users from choosing a compromised password when they reset the old one.

Start with 500 free creditsDocumentation

Password breaches · 1 credit per lookup · no monthly fee

Reset password

••••••••
••••••••••••

The problem

Password reset is where compromised passwords sneak back in. A user whose old password leaked resets to... a different password that also leaked. The reset flow felt secure and changed nothing.

With Encrata

Screen the new password during reset exactly as you would at signup. Breached candidates get rejected with a clear message before they take effect, so the reset flow actually upgrades the account's security instead of rotating between compromised credentials.

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

Reset 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
}

The same gate at reset

Apply the identical check in the reset flow that you run at signup, same endpoint, same client-side hashing, same rejection copy. Resets deserve extra scrutiny: a user resetting because of a compromise is exactly the user most likely to rotate between passwords that are all in the same dump.

Resets that actually secure

Unscreened resets quietly undo your security work, the account that was 'secured' with another breached password is still one stuffing list away from takeover. Screened resets close the loop, and the found count in the response lets you calibrate: reject anything found at all on sensitive accounts, or set a threshold for lower-stakes ones.

More password breaches use cases

View all

Choose password

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

Password Screening

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

SaaSAuthentication

Password compromised

Seen in a public breach dump

Change password

User Alerts

Warn users still relying on passwords that have already appeared in known breaches

CybersecurityNotification

Password policy

12+ characters
Not in breach data
Rotated ≤ 90 days

Policy Enforcement

Screen employee passwords against breach databases to enforce your security policy

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