IDENTITY SECURITY · LAB

Threat-model your tenant's password reset

Draw your tenant's real reset flow, walk it with the lesson's five questions using ordinary reset requests, and record each finding with impact, likelihood and a decision.

Partly readyUses your lab tenant

The lesson

Threat modeling an identity systemPractices Before choosing defenses, What needs protecting, Walking a flow as an attacker, Deciding what to fix first

Builds on: Why attackers go after identity.

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
G36 Detection, risk signals, tenant metrics and alerts (baselines, anomaly rules, thresholds that notify an admin)
G37 Security context in Audit (network, device, session, method; subject on failed sign-ins) and user "this wasn't me" reporting

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.

Create Mia with your own inbox
Recorded as tenant.users.create succeeded.
Request a reset for Mia
Recorded as account.reset_password succeeded (reset_requested).
A known breached password is refused
Recorded as account.reset_password rejected (compromised_password).
Complete the reset with a strong password
Recorded as account.reset_password succeeded (reset_completed).

Setup

Press Start on this page.
Store Mia's address, a plus-address of your own inbox, in your shell.

export MIA_EMAIL="[email protected]"

Open a notes file for the model. It has three parts: the flow drawing, the five-question walk, and a findings table with the columns threat, impact, likelihood and decision.

Walkthrough

In Users, create Mia Lane with $MIA_EMAIL and set an administrator password for her. Confirm in Authentication that Password is not Off, because the reset pages exist only while passwords are in use.

Why it matters: the lesson starts with the first threat-modeling question, "what are we building?" Mia's mailbox is now part of what you are building, and it sits entirely outside your tenant.

Draw the flow from the real pages: $ISSUER/reset-password (the request form), the emailed link, and $ISSUER/reset-password/complete (the new-password form). Mark the assets (the password hash, the reset challenge, Mia's sessions, Audit history), the entry points, and the trust boundary where the link leaves your tenant and passes through the mail provider and Mia's mailbox.

Why it matters: drawing the flow makes the lesson's uncomfortable fact visible. Whoever can read Mia's mailbox can reset her password. That is a property of the design, and the model should say so.

Request a reset for $MIA_EMAIL. Then request one for an address with no account, such as [email protected]. Compare the two pages.

Why it matters: this is the "done by someone else" question for the request step. Both addresses get the same "Check your email" page, so the form does not answer "does this account exist?" The request also changes nothing until the link is used.

Open the email in Mia's inbox and read the link's address without opening it yet. It carries a challenge id and a long random token. Neither is Mia's account ID.

Why it matters: the lesson contrasts a link with an account number beside the token against a token-only link. Here the server looks up which account the challenge belongs to in its own record, so nothing in the browser can point the reset at another account.

In a private window, sign in as Mia at $ISSUER/login and leave $ISSUER/account open there.

Why it matters: this sets up the "skip the cleanup" question. A reset is often how someone tries to throw an intruder out, so it must end sessions that already exist.

In the first window, open the link and choose a password that is known from breaches, such as Password1. The page refuses it. Then choose a long, unique password. The reset completes.

Why it matters: screening happens before the link is used up, so the refusal leaves the link working for a better choice. Known passwords are refused at the moment they are chosen, which the next lesson covers in detail.

Refresh the private window. Mia is signed out. Check Mia's inbox for the password-changed notice.

Why it matters: the walk does not end when the password changes. Your tenant ends the account's other sessions, its outstanding grants and its remembered browsers, and tells Mia, which answers the lesson's cleanup question.

Fill in the findings table for what you saw. Rate impact and likelihood for each row, write a decision (fix now, fix next, reduce, or accept with an owner and a reason), and add the dates or events that reopen the model.

Why it matters: the lesson's last section turns findings into prioritized decisions. An accepted risk needs someone with authority, a stated reason and a revisit trigger. A gap nobody noticed is not an accepted risk.

Break it

Open the link you just used again. The page says it is invalid, expired or already used. Single use answers "repeated."
Request two resets for Mia in a row, then open the link from the first email. It is refused, because a new request replaces earlier links. That answers "done out of order" and the lesson's "used or older links still work" row.
Request resets for Mia several more times until the page says "Too many requests. Try again later." The limit on each address answers the "flooded inbox" row. Nothing was weakened, so there is nothing to restore; wait for the window to pass.

Check your work

Check my progress confirms Mia's creation, the reset request, the refused breached password and the completed reset, in that order.
In Audit, source Protocol activity, the refused password has no subject, because it was refused before the link identified an account.
Your findings table has at least five rows, each with impact, likelihood and a decision, and a revisit trigger at the top.

Cleanup

Keep Mia and her new password. The recovery lab uses her again.
Store Mia's password in your shell when you need it with read -rs MIA_PASSWORD, never in the notes file.

Missing infrastructure

G36: your model's mitigation "flag an unusual reset" has nothing to verify, because the tenant records events but runs no detection or alerting. Once it exists, the lab will request a reset from a network Mia never used and confirm that an alert reaches the administrator.
G37: the tenant does not notify a previous address after a recent email change, and it records no source network or device with the reset. Once it exists, the lab will change Mia's address, reset her password, and confirm the old address also receives the notice.
G29: the password length and composition rules are fixed. A model decision such as "require a longer minimum" cannot be applied yet; once it exists, the lab will set the rule and confirm the reset form enforces it.

Back to all labs

Create a tenant