Welcome to the "A04: Insecure Design" course! In this lesson, we will explore the topic of insecure credential recovery mechanisms, specifically focusing on the use of security questions and answers. Credential recovery is a critical component of web applications, allowing users to regain access to their accounts. However, when implemented insecurely, it can become a significant vulnerability, effectively creating a "backdoor" into a user's account that bypasses the primary password authentication.

Let's dive into understanding these mechanisms and how they can be exploited. 🚀

Security questions are a form of Knowledge-Based Authentication (KBA), where a user must provide a pre-established piece of information ("something you know") to prove their identity. The underlying assumption is that these answers are private, static, and memorable. Common questions include "What's your mother's maiden name?", "What street did you grow up on?", or "What was your first pet's name?"

While this method seemed secure initially, it has several fundamental design flaws that have become more pronounced in the digital age. The primary security flaw is that the answers often have low entropy (meaning they are predictable) and are not truly secret. In the age of social media and public records, information like a mother's maiden name, hometown, or even a pet's name is often publicly discoverable. This makes them particularly vulnerable to targeted attacks.

Other outdated recovery methods share similar weaknesses:

• SMS-based recovery: Vulnerable to SIM swapping, where an attacker convinces a mobile carrier to transfer the victim's phone number to a SIM card they control.
• Simple PIN codes sent via email: If the user's email is already compromised, this offers no additional security.
• Birth date verification: This is public information and easily guessable.
• Last transaction amount (for banking): Can be phished or discovered through other means.

These methods fail because they rely on information that is either public, guessable, or can be intercepted, violating the core principle that authentication secrets must remain confidential.

Credential recovery mechanisms are processes designed to help users regain access to their accounts when they forget their passwords. The goal is to securely re-establish identity by balancing user convenience with robust security. The system must be able to reliably verify the user's identity through a secondary channel without introducing new weaknesses.

When implemented using security questions, the system compares a user-provided answer against a stored response. While this seems straightforward, it introduces several security risks because the answers are often predictable or publicly available information. Let's examine a vulnerable implementation that demonstrates these risks.

Let's examine a typical, flawed implementation of security question recovery. In this common but insecure design pattern, the application first verifies the user exists and then checks their security answer. This design is flawed from the start because it leaks information and relies on a weak secret.

Here is how the endpoint handles the initial recovery request in Python using FastAPI:

This code contains several critical design flaws:

1. User Enumeration: The code first checks if the user exists and returns a 404 Not Found error if they don't. This allows an attacker to determine which usernames are valid in the system by observing the different responses.
2. Weak Secret: The security answer is checked using a simple string comparison. Since these answers are often common names or places, they are susceptible to guessing or dictionary attacks.
3. Direct Password Disclosure: Upon a successful guess, a temporary password is generated and returned directly in the API response. This is extremely dangerous, as it hands control of the account to anyone who can guess the answer.
4. Lack of Protective Controls: The endpoint has no rate limiting or account lockout mechanisms. An attacker can make unlimited guesses without being blocked, making a brute-force attack trivial.

An attacker can exploit this insecure design by performing a dictionary attack. This attack vector involves creating a list of common or likely answers (the "dictionary") and systematically trying each one. Because the API confirms a correct answer and lacks rate limiting, this attack is highly effective.

Here's a simple Python script using the requests library to demonstrate such an attack, assuming the security question is "What was your first pet's name?":

This exploit script works by systematically iterating through a list of common_dog_names and sending a POST request for each one. The vulnerable API's design directly aids the attacker:

1. The script sends a guess.
2. The API responds with a 401 Unauthorized status if the guess is wrong.
3. If the guess is correct, the API responds with a 200 OK status and, critically, includes the new temporary password in the response body.
4. The script detects the successful response, prints the password, and stops.

The attacker can now immediately use this temporary password to log in, change the password to something they control, and take over the account.

Instead of relying on weak, guessable secrets, a more secure approach is to implement an email-based password reset system. This method is built on the principle of out-of-band verification, leveraging a separate communication channel (the user's email) to verify their identity. This has become an industry standard used by major platforms due to its robust security model.

The security of this method is multi-faceted and addresses the flaws of KBA:

• Trusted Secondary Channel: Email accounts serve as a trusted secondary authentication factor. They are separate from the application and are often protected by their own security measures, such as two-factor authentication (2FA).
• Time-Limited Tokens: The system generates a unique, single-use reset link that expires after a short period (e.g., 15-60 minutes). This minimizes the window of opportunity for an attacker to use a stolen or intercepted token.
• Cryptographically Secure Tokens: The tokens are generated using a cryptographically secure random number generator, making them practically impossible to guess.
• Audit Trail: Every reset attempt creates an audit trail through email notifications and application logs, providing visibility to both the user and security teams.

These features work together to create a robust system that's both secure and user-friendly. Let's examine an example implementation of this secure solution step by step.

First, let's look at how we handle the initial password reset request. Here is an improved and robust implementation using FastAPI and Python's standard libraries:

Notice how we now return the same message regardless of whether the user exists, preventing username enumeration. This is done for maximum security, but as mentioned above, you might want to reveal this information to users for a better user experience.

The reset token mechanism is a crucial part of secure password recovery. The reset_token is a cryptographically secure random string generated using secrets.token_urlsafe(32), which produces unpredictable tokens that serve as one-time password reset links. When stored in the database, the token is associated with the user's account and given an expiration timestamp.

This implementation creates a secure, time-limited token and sends it via email. The token acts like a temporary key — it must be unique, unpredictable, and should expire after a short period (in this case, one hour) to minimize the window of opportunity for potential attacks. The token is sent to the user via email, while it's stored in the database (either in raw form or hashed, depending on your security requirements).

In production systems, additional security layers like storing hashed tokens (rather than plaintext), rate limiting recovery requests, and invalidating active sessions after password changes provide defense-in-depth—some of which we'll cover in later lessons.

When the user clicks the reset link, we verify the token and update the password:

This implementation ensures that reset tokens are single-use and time-limited, significantly improving security over the security question approach.

In this lesson, we explored the vulnerabilities of using security questions for credential recovery and demonstrated how they can be exploited. We also discussed and implemented a secure email-based token system as a better alternative.

As you move forward, you'll have the opportunity to practice these concepts in the exercises that follow. In the next lesson, we'll continue to build on this foundation by exploring other common vulnerabilities and their mitigations. Keep up the great work! 🌟