HealthcareAccess

Account Protection

Require safer passwords on sensitive accounts where a takeover hurts the most.

Start with 500 free creditsDocumentation

Password breaches · 1 credit per lookup · no monthly fee

Patient portal

Sensitive · stricter screening

Breached passwords rejected

The problem

A breached password on a meme account is an annoyance; on a patient portal or a payroll account it's a reportable incident. High-stakes accounts need stricter screening than your standard signup flow applies.

With Encrata

Apply tiered screening: sensitive account types reject any password with breach history, while standard accounts might only reject high-count offenders. Same API, different threshold on the count field, protection proportional to what the account can lose.

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

Account Protection 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
}

Thresholds by sensitivity

Implement protection tiers as thresholds on the count field: standard accounts reject passwords found more than a handful of times, sensitive accounts (health, payroll, admin-adjacent) reject anything found at all. Same API call everywhere, the tier lives in your policy layer, not in the integration.

Protection that fits the stakes

Proportional protection is easier to defend than uniform protection: nobody argues the patient portal should accept a password from a breach dump, and hobbyist accounts don't inherit friction designed for higher stakes. When regulators or auditors ask how protection maps to data sensitivity, the tier table is the answer.

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

Reset password

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

Reset Screening

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

BankingSecurity

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
Start with 500 free credits
$curl https://encrata.com/api/agent/lookup -H "Authorization: Bearer YOUR_API_KEY" -d '{"e": "satya@microsoft.com"}'