Watch sign-in limits and breached-password screening work

Setup

1. Press Start on this page.

2. In Authentication, confirm Password is Required.

3. Use the browser sign-in page for every attempt in this lab. A handful of attempts from your own network is all the limits need, so no script is involved.

Walkthrough

1. At $ISSUER/login, sign in as [email protected] with a wrong password. The page says "The email or password is incorrect." Now try [email protected], an address with no account, with any password. The message is the same.

Why it matters: the lesson's account enumeration section. The same words and status for an unknown account and a wrong password, plus a hash comparison that runs even when there is no account, mean neither the reply nor its timing answers "does this account exist?"

2. Keep mistyping Ben's password from the same browser until the page answers "Too many attempts. Try again later."

Why it matters: this is throttling, not a hard lockout. The limit counts failures for Ben's address from your network, so someone typing wrong passwords elsewhere cannot lock Ben out everywhere. That is the lesson's alternative to a lockout anyone could trigger.

3. In Audit, source Protocol activity, filter the outcome to rejected. You see one account.sign_in event with reason invalid_credentials for each wrong password. None has a subject, including Ben's, because a typed address is a claim, not a signed-in user.

Why it matters: the lesson's "what guessing looks like in the records." The records hold no passwords. The shape comes from how many attempts, how close together, and why each failed.

4. In Logs, source Protocol summaries, find the account.sign_in summary for the refused attempts. It names the limit that refused them and counts the requests, with first and latest request ID samples.

Why it matters: an attempt the limit refused never reached the password check, so it is summarized in Logs rather than recorded as an individual Audit event. Knowing which limit acted tells you which shape of attack you are looking at.

5. In the portal, open Overview > Usage and limits. Find the limit on failed password sign-ins per address and network: it shows the count, the limit and when it resets, and no address or browser. When the reset time passes, sign in as Ben with his correct password. It works.

Why it matters: the defense slows guessing without permanently shutting out the owner. Under a hard lockout the owner would be stuck until someone unlocked the account.

6. In Users, open Ben and try to set his password to Password1. The portal refuses it as a password that has appeared in a breach.

Why it matters: credential stuffing works because people reuse passwords. Screening at the moment a password is chosen stops known passwords being chosen at all. The tenant checks with the k-anonymity lookup the lesson describes, so the password never leaves the tenant.

7. In Authentication, turn on Self-service registration and save. At $ISSUER/register, register with a new plus-address of your own and the password Password1. The page refuses it the same way.

Why it matters: every place a password is chosen needs the same check. A screen on the administrator's form but not on registration would leave the weakest path open.

Restore: turn Self-service registration off again unless you are going on to the Fake accounts lab, which uses it.

Break it

1. If the breach lookup cannot be reached, the tenant refuses the new password with password_screening_unavailable instead of accepting it unchecked. You cannot cause this yourself; look for it in Audit only if it ever appears. A check that fails closed is the safe default.

Check your work

• Check my progress confirms the wrong-password rejections, Ben's later sign-in, and the two breached-password refusals.

• In Audit, source User directory, the refused tenant.users.credentials.set shows reason compromised_password and names you as the actor.

• In Audit, source Protocol activity, account.register is rejected with compromised_password.

Cleanup

• Keep Ben's strong password. Do not reuse it anywhere else.

• If you registered a test account successfully afterwards, delete it in Users.