Capability

Breached passwords

What it does: Refuses passwords already exposed in other breaches.

CIC

In short

Many customers reuse one password on several services. When one of them is breached, attackers try the leaked password everywhere else. Breached password detection in Auth0 flags such sign-ins and can block them or notify the user. The check uses breach data Auth0 maintains.12

Book a callHow Auth0 does it ↓
4
attack types it helps against

What it is, and the attacks it stops

Many customers use the same password on several services. When one of those services is breached, the leaked password becomes a ready key to every other account where the customer reused it.

Breached password detection compares credentials at sign-in or password change with credentials known to be exposed in breaches of other services. Note: it does not scan every stored password in your directory on its own.1

That helps against attacks such as:

1

Credential stuffing

Attackers try leaked email and password pairs on your login page. A pair that is already public is the first one they try.

2

Targeted account takeover

An attacker looks up a specific customer in leaked data and signs in with the password found there.

3

Common passwords that appear in many breaches

Passwords that show up in many breaches are the ones attackers try first.

4

Takeovers that look like normal sign-ins

The attacker enters the correct password, so nothing in the login flow looks wrong.

Before and after rollout

Without
With
WithoutA leaked password works on your site until the customer happens to change it.
WithA sign-in with a password exposed in a breach can be blocked, and the customer can be notified.1
WithoutThe first sign that a password leaked is the account takeover.
WithA sign-in that uses exposed credentials can be flagged before it turns into a takeover.1
WithoutYour team hears about leaks only when a customer complains.
WithFlagged sign-ins can be reviewed in Auth0, so your team sees them without waiting for a complaint.1
WithoutEvery customer has to judge on their own whether a password is safe.
WithThe check happens at sign-in, so the customer does not have to know whether a password leaked.1

How Auth0 does it

Auth0 Breached Password Detection works at sign-in, and you choose what happens when it finds a match.1

1

The customer signs in

The customer enters an email and a password on a login page backed by Auth0.1

2

Auth0 compares the credentials

Auth0 checks whether the credentials match ones exposed in a breach of another service.1

3

Auth0 applies the configured response

Depending on the settings, Auth0 can respond in ways such as blocking the sign-in or notifying the user.1

4

The customer sets a new password

The customer then chooses a new password, usually through a password reset. Password strength settings help keep weak choices out.4

CIC
Who it protectsYour app's users
Breached Password DetectionAuth0 Attack Protection includes breached password detection on supported plans. It checks credentials at authentication time against breach data.12
Configurable responseYou can choose responses such as blocking the sign-in or notifying the user.1
Password strength settingsAuth0 database connections offer password policy settings that set minimum rules for new passwords.4
PasskeysAuth0 database connections support passkeys, so a customer does not need a reusable password at all.3

How Zelto implements it

Auth0 provides the detection - Zelto decides with you what happens after a match, so that the protection does not turn into a wave of support calls. We start from how your customers sign in and reset passwords today. We plan the change in stages to minimize risk/impact, and we keep a recovery path that attackers cannot talk their way into.

Typical rollout

  1. Map how customers sign in and recover access

    We list your login flows, Auth0 database connections and password reset paths.

  2. Choose the response

    For each flow, we agree whether a match blocks the sign-in, notifies the customer or both, and who on your side owns that decision.

  3. Prepare the customer message and the recovery path

    We write the notification and the reset steps so that a blocked customer knows what to do. The reset path checks who the customer is before it accepts a new password.

  4. Switch on in stages

    We enable the protection in a test environment first and then in production, one customer group at a time. We watch the volume of flagged sign-ins before we tighten any setting.

  5. Review and move toward passkeys

    We review flagged sign-ins on a schedule. Where it fits, we move customers to passkeys, so that no reusable password is left to leak.

Pitfalls we plan for

A customer signs in with a password that appears in a breach.

−Block the sign-in with a generic error and no explanation. The customer calls support or leaves.

+Block or flag the sign-in, tell the customer why, and send them to a password reset.

A blocked customer asks for a password reset.

−Send the reset link to any address on request, without checking who is asking.

+Send the reset only to the verified address on the account, and require a new password that is not on a breach list.

Many existing customers use leaked passwords, and the protection is switched on for all of them on the same day.

−A large group is blocked at once and support is overwhelmed.

+Switch on in stages, give support a script for each group and fix a date per group.

Breached password detection is the only protection on the login page.

−A customer with a unique password is assumed safe, while scripted attacks and password guessing go unnoticed.

+Combine it with bot detection and IP throttling, and offer passkeys, so that no single control carries the whole login page.

Want leaked passwords to stop opening customer accounts?

We review how your customers sign in and reset passwords today. Then we tell you what to change first.

Book a call30 minutes, no slides. We look at your customer login flows today.

Related blog posts

Notes from rollouts

C Is For Credentials: Practical Hygiene and Secrets ManagementRead on the blog →H Is For Hashing: Elevating Identity Security Beyond Basic PasswordsRead on the blog →

Sources

Official Okta and Auth0 documentation and primary legal sources.

  1. 1Breached password detectionAuth0 Docs
  2. 2Attack protectionAuth0 Docs
  3. 3Passkeys in Auth0 database connectionsAuth0 Docs
  4. 4Password strength in database connectionsAuth0 Docs