AUTHENTICATION METHODS · LAB

See what the tenant does with a password

Watch the tenant refuse breached and rule-breaking passwords, trigger its online guessing limit, and compare a remote password with a PIN that only your authenticator checks.

Partly readyUses your lab tenant

The lesson

Passwords and PINsPractices A familiar secret, Checking a password, Where passwords fail, A PIN on your device

Builds on: Methods, credentials, and factors.

New to the labs? Start with the lab toolkit and the shared cast and names every lab uses.

Partly ready. Most of this lab runs today. Steps that wait on platform features are marked, and Missing infrastructure says what they need.

G29 Tenant-configurable password policy

Your progress

Press Start before you begin. Only events your tenant records after that count, in the order below. Checking reads your tenant's Audit, so you need Audit read access in it.

Try a breached password for Cora
Recorded as tenant.users.credentials.set rejected about [email protected].
Set Cora a strong unique password
Recorded as tenant.users.credentials.set succeeded about [email protected].
Fail Cora's password at the sign-in page
Recorded as account.sign_in rejected (invalid_credentials).

Setup

Complete Follow the evidence in a real sign-in first, so Ava, Ben and Cora have passwords.
This lab uses Cora for the password and lockout steps, so Ava and Ben stay usable for the next labs.
Open a private browser window for Cora.

Walkthrough

In the portal open Users > Cora > Set password and enter Password123!. It satisfies the composition rule, yet the tenant refuses it because the value appears in breach data.

Why it matters: the tenant screens new passwords against lists of breached values with a range query, so the password itself never leaves the tenant. This is the check the lesson's NIST guidance asks for.

Try Summer2026! and note the result. Whether or not it appears in breach data, it is exactly the predictable pattern the lesson warns that capital, digit and symbol rules produce.

Why it matters: composition rules push people toward the same few shapes, and those shapes are the first guesses anyone tries.

Try a long lowercase passphrase with spaces, such as river lantern copper meadow thistle. It is refused: spaces do not count as a symbol, so only one character class is present.

Why it matters: this is the composition rule SP 800-63B-4 advises against, which would accept the passphrase on length alone. The rule is fixed in this tenant (G29), so you can observe it but not change it.

Set Cora a long, unique password generated by your password manager and save it there.

Why it matters: a unique password keeps a breach at another site from handing over a working password here.

Optional, a check that no readable copy exists. Open the SCIM console at /docs/scim/. If lab-scim-reader does not exist yet, create it there with only the read scope scim-<id6>.read. Request a token for it and send this lookup, with the token in SCIM:

curl -s -G -H "Authorization: Bearer $SCIM" "$ISSUER/scim/v2/Users" \
  --data-urlencode 'filter=userName eq "[email protected]"' --data-urlencode 'attributes=password' | jq .

No password is returned, whatever attributes you ask for.

Why it matters: the tenant stores a salted, slow hash, so there is no password to show back, to an administrator or to anyone who copies the store.

In Cora's window open $ISSUER/login. Submit Cora's address with a wrong password five times, then with the correct password. The sixth attempt is refused with "Too many attempts. Try again later." and HTTP 429.

Why it matters: online guessing is limited per address and network. While the limit is active even the correct password is not checked, so a guesser learns nothing from a lucky guess.

In the portal open the tenant usage view. The limit Failed password sign-ins per address and network shows the attempts and when the window resets.

Why it matters: a limit people can hit should be a limit they can see. The window is 15 minutes, which is the lesson's online attack slowed to a crawl.

If you have finished Register and use a passkey bound to your tenant, or own a security key with a PIN, sign in with it as Ava through $ISSUER/token-decoder. The ID token's amr contains hwk or swk and mfa, and no pwd.

Why it matters: the PIN was checked by the authenticator on your device. The tenant received only a signed response saying the user was verified, never the PIN.

Break it

The breached password in step 1 is refused, and Cora's existing password stays unchanged. Audit shows tenant.users.credentials.set rejected.
The lockout in step 6 is refused before the password is checked. The five wrong attempts appear in Audit as account.sign_in rejected with reason invalid_credentials. The refused sixth attempt is counted in Logs with reason rate_limited.

Restore: the lockout is a platform protection, not a tenant setting. Wait 15 minutes before signing in as Cora again.

Check your work

Press Check my progress. The checks look for the refused breached password, the strong password you set, and the failed guesses at the sign-in page.

Also confirm by hand:

Logs show account.sign_in rejected with reason rate_limited for the sixth attempt.
The tenant usage view showed the sign-in limit with its reset time.

Cleanup

Wait out the 15-minute window before using Cora again. Keep her new password in your password manager.

Missing infrastructure

G29, tenant-configurable password policy. Password rules are fixed at 8 to 128 characters with three of four character classes. Once the tenant can choose its policy, step 3 becomes a change: set "at least 15 characters, no composition rule, breach screening on", watch the same passphrase succeed, then require 8 characters only for users who have a second factor, as SP 800-63B-4 allows.

Back to all labs

Create a tenant