Draw the login request, the credential store and the session, then ask the six STRIDE questions at each point. The usual findings are guessable credentials, account enumeration through error messages, lockout used as a weapon, and weak sessions. OWASP's authentication guidance gives a mitigation for each.
The diagram
Four elements are enough: the browser, the login endpoint, the credential store and the session store. Trust boundaries sit between the browser and the endpoint, and between the endpoint and the stores.
STRIDE walk through
| STRIDE | Login threat | Mitigation from OWASP guidance |
|---|---|---|
| Spoofing | Attacker logs in as someone else with guessed or breached passwords | Offer MFA, screen against breached or common password lists, allow long passphrases |
| Tampering | Session token altered or predicted | Make sessions unique and very hard to predict; serve all authenticated pages over TLS |
| Repudiation | Failed logins and lockouts go unnoticed | Log and review authentication failures and lockouts |
| Information disclosure | Different errors reveal which usernames exist | Return one generic message, with consistent timing and status codes |
| Denial of service | Attacker locks out real users on purpose | Avoid lockouts that deny service to others; allow recovery while locked |
| Elevation of privilege | Session kept after a sensitive action or role change | Invalidate and rotate tokens after re-authentication |
Details worth copying
The OWASP Authentication Cheat Sheet makes several specific points.
- Enforce a minimum length and allow a maximum of at least 64 characters.
- Do not impose composition rules, and do not force periodic changes. Rotate credentials when a leak is suspected.
- Tie the failed login counter to the account, not only to the source address, so rotating addresses does not help an attacker.
- Use rate limiting, a lockout threshold, an observation window and a lockout duration. Exponential delays are an option.
- Treat CAPTCHA as defense in depth, possibly only after a few failures.
Record the decisions
For each row, record a response (mitigate, eliminate, transfer, accept), an owner and a test. Examples of tests: two wrong-user and wrong-password attempts return identical responses, the tenth failed attempt triggers the limit, and a session cookie is replaced after a password change.
Where login threat models go wrong
- Modeling only the password form and forgetting recovery, which is often the weaker door. See the secure password reset flow checklist.
- Ignoring logging, which means attacks happen unseen.
- Treating MFA as a full answer when recovery can bypass it.
Try it yourself
Click through it at your own pace, or open it full screen. Click through it and look at how a code scan reports issues in the code behind a login handler.
Quick check
Should the lockout counter track the IP address?
OWASP advises tying it to the account, so that rotating source addresses does not evade it. Combine it with other limits and avoid lockouts that let an attacker block real users.
Do I still need password rules like symbols and numbers?
The OWASP guidance says not to impose composition rules. It recommends length, passphrase support and screening against breached or common passwords instead.
A note on tooling
Safeguard covers the code and dependency side of authentication work: SBOM and dependency scanning, reachability analysis and policy gates on pull requests. Try the free scan on the repository behind your login service.
Sources
Last reviewed: 19 October 2026.
