Katkat
Back

Design a Pre-Login Risk and Challenge Service

SnapchatSoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

Design a low-latency, resilient pre-login security service that evaluates risk signals, issues dynamic verification challenges, and verifies responses without exposing authentication flows to replay attacks.

Scenario

A mobile-first social platform handles tens of thousands of login attempts per second. To combat credential stuffing, bot attacks, and account takeovers, the platform requires a dedicated Pre-Login Risk and Challenge Service. When a client attempts to sign in, the system must evaluate request signals (device fingerprint, IP reputation, velocity counters), determine whether the attempt is benign, suspicious, or malicious, and dynamically issue and verify step-up challenges (e.g., CAPTCHA, SMS/Email OTP, Device Push) before granting full session tokens.

Requirements

Functional Requirements

  • Risk Evaluation & Challenge Selection: Ingest client context and evaluate risk to decide whether to allow the request, issue a specific challenge, or block the attempt outright.
  • Dynamic & Versioned Challenges: Serve challenge metadata to clients using versioned configurations (e.g., third-party CAPTCHA v2, SMS OTP v1) so challenge providers and parameters can change without client app updates.
  • Secure Verification & Replay Protection: Validate challenge responses server-side. Ensure challenge sessions are strictly single-use, bounded by a strict TTL, and bound to the original device and user identity.
  • Fallback and Recovery: Allow legitimate users who cannot complete a primary challenge (e.g., SMS delivery failure) to request approved alternative paths while enforcing strict rate limits.

Non-Functional Requirements

  • Scale: 100 million Daily Active Users (DAU); 50,000 peak login requests per second.
  • Latency: p99 latency < 50ms for initial risk evaluation and challenge issuance; p99 < 100ms for challenge verification.
  • Availability: 99.999% availability. The system must have a clearly defined graceful degradation strategy during vendor or database outages.
  • Security: Zero leakage of user existence prior to credential submission; zero replayability of challenge tokens.

What to Cover

  1. API Design: Define endpoints for challenge evaluation, initiation, and verification.
  2. Architecture & Request Flow: Diagram interactions between the API Gateway, Risk Assessment Engine, Challenge Orchestrator, and persistent/ephemeral stores.
  3. State Management & Cryptographic Binding: How challenge tokens are generated, stored, verified, and invalidated atomically.
  4. Failure Modes & Trade-offs: Strategy for vendor outages (e.g., SMS provider or CAPTCHA vendor down), cache eviction, and fail-open vs. fail-closed trade-offs.

Hints

Hint 1

Consider binding the issued challenge token cryptographically to an ephemeral HMAC of the client's device ID and TLS fingerprint to prevent token transferability.

Hint 2

Decouple heavy risk signal computations (e.g., graph lookups, deep learning models) into pre-computed streaming features so synchronous evaluation remains under 50ms.

Hint 3

Use atomic distributed operations (such as Redis GETDEL or conditional writes in DynamoDB) to guarantee that a challenge completion token cannot be replayed concurrently.

Follow-up questions

  • How does your architecture mitigate distributed credential stuffing attacks originating from rotating residential proxies where each IP only submits a single request?
  • If your primary third-party CAPTCHA provider experiences an outage, how does your orchestrator fail over without degrading into a complete fail-open state?
  • How do you prevent attackers from using the challenge selection endpoint to enumerate valid usernames or active phone numbers?