STRIDE Walkthrough — Customer Authentication System

Table of contents

Overview

This walkthrough demonstrates every step of the threat modelling workflow using a realistic example: a customer authentication service for an e-commerce platform.

By the end you will have a complete threat model with scored threats, documented mitigations, residual risk scores, and formal security requirements — ready to export as a PDF or JSON.

System: Customer Authentication Service
Scope: User registration, login, password reset, and session management
Data classification: Confidential (credentials, session tokens, PII)
Regulations in scope: UK GDPR, PCI-DSS (card-holder data adjacent)

Step 1 — Application Info

Fill in the Application Info step to establish the identity and context of the model.

Step 2 — Scope & Decomposition

Trust Levels

Define who and what can interact with the system, and how much they are trusted.

Threat Agents

External Dependencies

Business Context

Business criticality: Critical — authentication is a prerequisite for all customer activity
Data classification: Confidential — stores password hashes, session tokens, email addresses

Step 3 — System & Data Flow Diagram

Components

Data Flows

Trust boundary crossings to flag: Login request and session token both cross the public internet boundary. Password reset email crosses into a third-party service we do not control.

Step 4 — Threat Identification

Apply STRIDE to each component and trust boundary crossing. Below are the key threats identified.

Spoofing

S1 — Credential Stuffing
Target: Auth API — Login endpoint
Using automated tools and leaked credential databases, an attacker submits thousands of known username/password pairs. Even a 0.5% hit rate against 1M accounts yields 5,000 takeovers.

S2 — Session Hijacking
Target: Session token (Browser → Auth API data flow)
An attacker obtains a valid session cookie via XSS or network interception and replays it to impersonate the victim without knowing their password.

S3 — Password Reset Token Abuse
Target: Auth API — Password reset endpoint
Reset tokens sent by email are short-lived but predictable if generated with a weak PRNG. An attacker who can also read the victim’s email (compromised inbox) completes an account takeover silently.

Tampering

T1 — SQL Injection
Target: PostgreSQL via Auth API
If user-supplied input reaches database queries without parameterisation, an attacker can modify or delete user records, bypass authentication, or extract the full user table.

T2 — Redis Session Poisoning
Target: Redis Session Store
If Redis is reachable without authentication (a common misconfiguration), an attacker with network access can write arbitrary session data — effectively issuing themselves a valid admin session.

Repudiation

R1 — Missing Authentication Audit Trail
Target: PostgreSQL — Audit log table
Without immutable logging of login successes, failures, and password changes, it is impossible to establish a timeline after a breach. Attackers can deny activity; victims cannot be notified.

Information Disclosure

I1 — Username Enumeration
Target: Auth API — Login and reset endpoints
Different error responses for valid vs invalid email addresses allow attackers to silently build a list of registered users, which is then used for targeted phishing or credential stuffing.

I2 — Password Hash Exposure
Target: PostgreSQL
A SQL injection or misconfigured database backup exposes password hashes. If hashes use MD5 or unsalted SHA-1, an attacker can crack them offline using rainbow tables or GPU brute-force within hours.

I3 — Verbose Error Messages
Target: Auth API
Unhandled exceptions return stack traces, framework versions, or raw database errors to the client — disclosing the technology stack and potentially exposing internal file paths.

Denial of Service

D1 — Targeted Account Lockout
Target: Auth API — Login endpoint
An attacker deliberately triggers failed login attempts against a known account to lock it out, denying service to the legitimate user without needing to know their password.

D2 — Login Endpoint Flood
Target: Auth API
A volumetric attack exhausts available CPU and connection pool resources on the login endpoint, making the system unavailable to all users.

Elevation of Privilege

E1 — Mass Assignment on Profile Update
Target: Auth API — User update endpoint
If the profile update endpoint accepts arbitrary JSON fields, a crafted request including "role": "admin" or "is_verified": true can elevate privileges without authorisation.

Step 5 — Risk Assessment

Score each threat on a 5×5 Likelihood × Impact matrix.

Step 6 — Countermeasures

Document controls for each threat. The residual risk score is re-assessed after mitigations are applied.

S1 — Credential Stuffing (Critical → residual: Low)

Residual likelihood: 1 Residual impact: 3 Residual score: 3 — Low

T1 — SQL Injection (High → residual: Info)

Residual likelihood: 1 Residual impact: 1 Residual score: 1 — Info

E1 — Mass Assignment (High → residual: Low)

Residual likelihood: 1 Residual impact: 2 Residual score: 2 — Low

S2 — Session Hijacking (High → residual: Low)

Residual likelihood: 2 Residual impact: 2 Residual score: 4 — Low

I2 — Password Hash Exposure (Medium → residual: Low)

Residual likelihood: 1 Residual impact: 2 Residual score: 2 — Low

Step 7 — Security Requirements

Formal requirements derived from the threats above. These can be linked to tickets in your backlog and used as acceptance criteria.

Step 8 — Report

After completing all steps, the Report step gives you:

• A full threat register with all 12 threats, scores, and statuses
• Mitigation progress summary (3 Implemented, 2 In Progress, 7 Planned)
• Residual risk comparison table showing risk reduction per threat
• Security requirements list ready to paste into your backlog

Use Download PDF to generate an audit-ready report, or Export JSON to save the model and share it with your team.

Key Takeaways

Credential stuffing is the single highest risk for any consumer authentication system. It is trivially easy to execute (tools are freely available) and has a high impact rate. Rate limiting, CAPTCHA, and MFA together reduce this from Critical to Low.

Mass assignment is a silent privilege escalation vector. It rarely shows up in automated scans but is catastrophic if exploited. A simple allowlist on the update endpoint eliminates it entirely.

Residual risk after mitigations tells the real story. This model starts with one Critical and four High threats. After applying the planned controls, every threat drops to Medium or below — giving the team a clear picture of what to build before launch.

Export this model as JSON and share it with your security team for review, or use the PDF export for inclusion in a pre-launch security sign-off document.