Reasoning Checkpoint
A design challenge, worked through in writing — no auto-grading, just a real attempt.
The Challenge
John asks Anna to threat-model BlueTicket's login and checkout: look at each step through an attacker's eyes, list what could go wrong, and say what protects against it.
Login: a fan enters email and password (or uses "Sign in with Google"), optionally an MFA code, and receives a session cookie. Checkout: the fan picks seats, enters a promo code, the seats are held for 15 minutes (Act 08), the payment is sent to the payment provider with an API key, and a confirmation email is sent.
What Your Threat Model Needs
- For login, list at least four threats (what an attacker could do) and the protection for each.
- For checkout, list at least four threats and the protection for each.
- For each threat, say which idea from this Act it relates to (authentication, authorization, hashing, sessions, encryption, secrets, injection, XSS, CSRF, dependencies, abuse).
- Pick the single threat you think is most dangerous, and explain why.
- Name two ways the team would notice if one of these attacks was happening.
Stuck? A Few Hints
- For every field, ask: what could someone type here?
- For every action, ask: what if someone does this a million times?
- For every secret, ask: what if it leaks?
Before You Move On
Threat modelling isn't about finding every possible attack — it's about asking the attacker's questions on purpose, before an attacker does. If your list covers logins, money, inputs, secrets and abuse, you're already thinking the way security teams do.