Design an account takeover detection system

Account takeover (ATO) is an attacker gaining control of a real user's account. Credential stuffing replays username and password pairs leaked from other sites; success rates are typically 0.1 to 2 % because people reuse passwords. Password spraying is the inverse: a few common passwords tried against many accounts, slowly, to stay under lockout. Adversary-in-the-middle (AiTM) phishing kits proxy the real login page and steal the session cookie after MFA succeeds, so the attacker never needs the password again.

Functional requirements

1. Score every login attempt and return a decision to the identity service: allow, step-up, block, or allow and notify.
2. Score sensitive in-session events (change email, add payout account, export data) and session anomalies (cookie used from a new device or network).
3. Detect population-level attacks (stuffing, spraying) and turn on defences automatically.
4. Collect labels from users and analysts and expose cases to the trust and safety team.

Non-functional requirements

1. 50 M users, 5 M logins a day; attacks can add 10k attempts/s.
2. Login risk decision < 50 ms p99 (the user is waiting).
3. If the risk engine is down, logins still work with a safe default.
4. Features and decisions are explainable to analysts and to users who appeal.

Back of the envelope

normal logins        5,000,000 / day           ≈ 58 / s average, ~300 / s peak (x5)
attack traffic       up to 10,000 attempts / s  -> design for 10,300 / s at the edge of the risk API
session events       50 per active session x 10 M sessions / day = 500 M / day ≈ 5,800 / s
user profiles        50 M x 2 kB (known devices, countries, ASNs, typical hours) = 100 GB
  -> key-value store, 3 replicas = 300 GB, a few memory-optimised nodes
risk decisions log   (5 M + 500 M sampled at 10 %) x 1 kB ≈ 55 GB / day

Login-time signals

Why per-IP limits fail

stuffing run         1,000,000 leaked pairs, 0.5 % success  -> 5,000 accounts taken
rate                 2,000 attempts / s
proxy pool           50,000 residential IPs
per IP               2,000 / 50,000 = 0.04 / s = 2.4 attempts / min
per-IP limit         10 / min  -> never fires
whole run            1,000,000 / 2,000 = 500 s ≈ 8 minutes

what does fire: global failure ratio jumps from ~8 % to ~95 %,
unknown-username share jumps, one JA4 + ASN pair carries 70 % of failures

After login: session anomaly scoring

AiTM kits steal the session cookie after MFA, so login-time checks all pass. The defence is to watch the session: the cookie was issued to one device fingerprint, network and user agent; if it is presented from a different JA4, a hosting ASN in another country, or a different User-Agent, that is a strong signal. Score sensitive events (change email, add a forwarding rule, add a payout account) with the session's history, not just the current request. Long term, bind sessions to a device key (Device Bound Session Credentials, or token binding through mTLS) so a copied cookie is useless.

Impossible travel, done carefully

Compute great-circle (haversine) distance between the geolocated IPs of two successful authentications and divide by elapsed time. Above roughly 1,000 km/h (faster than an airliner) the pair is physically impossible for one person. London to New York is about 5,570 km; two logins two hours apart imply 2,785 km/h.

const EARTH_KM = 6371;

interface Geo { lat: number; lon: number; accuracyKm: number; atMs: number; asnType: string }

function haversineKm(a: Geo, b: Geo): number {
  const rad = (d: number) => (d * Math.PI) / 180;
  const dLat = rad(b.lat - a.lat);
  const dLon = rad(b.lon - a.lon);
  const h = Math.sin(dLat / 2) ** 2 + Math.cos(rad(a.lat)) * Math.cos(rad(b.lat)) * Math.sin(dLon / 2) ** 2;
  return 2 * EARTH_KM * Math.asin(Math.min(1, Math.sqrt(h)));
}

const valid = (g: Geo) =>
  Number.isFinite(g.lat) && Math.abs(g.lat) <= 90 && Number.isFinite(g.lon) && Math.abs(g.lon) <= 180 &&
  Number.isFinite(g.atMs) && g.accuracyKm >= 0;

/** Returns a 0..1 contribution to risk, never a verdict on its own. */
export function travelRisk(prev: Geo, cur: Geo): number {
  if (!valid(prev) || !valid(cur) || cur.atMs <= prev.atMs) return 0;
  if (prev.asnType === "vpn" || cur.asnType === "vpn" || cur.asnType === "mobile") return 0.1; // geo unreliable
  const km = Math.max(0, haversineKm(prev, cur) - prev.accuracyKm - cur.accuracyKm); // subtract geo error
  const hours = Math.max((cur.atMs - prev.atMs) / 3_600_000, 1 / 60);               // floor at 1 minute
  const kmh = km / hours;
  if (kmh < 1000) return 0;
  return Math.min(1, 0.4 + kmh / 20000);
}

The risk engine

• Inputs: request context (IP, ASN, JA4, bot score from the edge), user profile, live counters, the action being attempted.
• Scoring: hard rules first (credential in breach corpus and no MFA enrolled, account flagged by analyst), then a gradient-boosted model over around 100 features, then a policy table mapping score band and action sensitivity to a decision.
• Latency: profile read and counter reads in one batched call (2 to 5 ms), model under 2 ms, no synchronous call to anything slower. Breach-corpus lookups are a local Bloom filter or a cached range table.
• Explainability: return the top contributing features as reason codes (new_device, travel_kmh_2785, stuffing_wave_active) so analysts and the user notification can say what happened.

Step-up integration

The risk engine does not run MFA; it returns { decision: "step_up", acr: "phr", maxAgeSec: 300, reasons } and the IdP asks the MFA service. Prefer phishing-resistant factors for high-risk step-up, because an attacker mid-AiTM can relay a TOTP code or a push approval. After a successful step-up from a new device, add that device to the profile only after a delay (for example 24 h without a user report) so one takeover does not teach the model the attacker is normal.

Population defences that switch on automatically

• When the global failure ratio or unknown-username share crosses a threshold, enter wave mode: raise bot ladder thresholds on the login route, require step-up for any login from a new device, and slow responses for failed logins by a few hundred milliseconds.
• Return the same response and timing for unknown user and wrong password, so the attacker cannot validate usernames.
• Force a password reset for accounts where a successful login used a credential found in a breach corpus.

Where labels come from

Failure modes

Trade-offs to state