Design a Pre-Login Risk and Challenge Service

Design a system that uses information available before a user logs in to decide which challenges the user must complete. CAPTCHA is one possible challenge. The reported design discussion included an operation that evaluates user risk and returns a challenge list, plus an “add challenge” operation. Clarify what adding a challenge means before choosing the interface and authority for it. ### Part 1 — Assess risk and select challenges What information can the service use before authentication, and how does it turn that information into challenge requirements? #### What This Part Should Cover - Trustworthiness and availability of pre-login signals. - A policy that balances protection, completion friction, and unsupported challenge types. ### Part 2 — Define interfaces and state Describe the evaluation response, challenge lifecycle, and the meaning and authorization of the add operation. #### What This Part Should Cover - Separation between challenge definitions and instances issued for a login attempt. - State and versioning needed to make the challenge list enforceable. ### Part 3 — Verify completion and integrate with login How does the login service know the required challenges were completed, and what happens during retries, expiration, or a challenge-provider failure? #### What This Part Should Cover - Server-side verification, binding to the intended attempt, and replay prevention. - A defined fallback policy and observability of user and security outcomes. ### What a Strong Answer Covers - An end-to-end flow from pre-login context to enforceable challenge completion. - Clear separation of bot friction, risk assessment, and user authentication. - Explicit assumptions about the ambiguous add operation and policy choices. ### Follow-up Questions - How would you prevent a client from discarding one item from the returned challenge list? - What would you change if a challenge type became unavailable or unusable for a group of legitimate users?