CWE-204: Observable response discrepancy (user enumeration)

[DogukanUrker]

Security Issue: CWE-204 - Observable Response Discrepancy

Severity: Medium
CVSS: 5.3

Description

Login and password reset endpoints return different error messages for 'user not found' vs 'wrong password', enabling user enumeration attacks.

Attack Vector

An attacker can determine if an email address is registered by observing the different error responses.

Fix Required

1. Use identical error messages for all authentication failures
2. Example: 'Invalid email or password' for both cases
3. Apply same approach to password reset endpoint

References

• CWE-204: Observable response discrepancy

[DogukanUrker]

🤖 AI-generated implementation plan — local LLM (ornith-35b) via Hermes Agent.
Not human-reviewed. Do NOT merge or act on this without human approval.

Problem

CWE-204: Observable response discrepancy in the login endpoint enables user enumeration. An attacker can determine whether a username is registered by observing different error messages.

• app/routes/login.py:63-68 — when user is not found: flash_message(page="login", message="not_found") → renders "User not found"
• app/routes/login.py:89-94 — when password is wrong: flash_message(page="login", message="password") → renders "Wrong password"

These two distinct messages leak information about account existence.

Current state in main

At current HEAD the login endpoint (app/routes/login.py:23-105) still returns two different error messages for authentication failures. The new app/utils/route_guards.py and the rewritten routes (verify_user.py, change_password.py, post.py) do not address this specific issue — they guard route access but do not normalize auth failure responses.

The password reset endpoint (app/routes/password_reset.py:116-119) requires BOTH username and email to match before sending a code, so it does not have the same CWE-204 vector. However, the password reset not_found message (app/routes/password_reset.py:170-176) could still leak whether a username exists if the email is wrong. This is a secondary concern.

Root cause

The login route uses two separate flash message keys ("not_found" and "password") that map to different user-visible strings. There is no generic/ambiguous error message for authentication failures.

Proposed fix

1. Add a new flash message key "invalid_credentials" (or reuse an existing generic one) with the value "Invalid username or password" (the app authenticates by username, not email).
2. Update app/routes/login.py — change the "user not found" branch (:63-68) to use the new generic message instead of "not_found". The "wrong password" branch (:89-94) should also use this same generic message.
3. Update app/translations/*.json — add the new key to all 12 translation files (en, tr, es, de, zh, fr, uk, ru, pt, ja, pl, hi).
4. Consider password reset — optionally change app/routes/password_reset.py:170-176 to also use a generic message like "If this account exists, a reset code has been sent" to prevent username enumeration via the reset flow. This is lower priority since the reset flow requires both username and email.

Files to change

• app/routes/login.py — unify both error branches to use a single generic flash message key
• app/translations/en.json — add "invalid_credentials": "Invalid username or password" under flash.login
• app/translations/tr.json — add Turkish translation
• app/translations/es.json — add Spanish translation
• app/translations/de.json — add German translation
• app/translations/zh.json — add Chinese translation
• app/translations/fr.json — add French translation
• app/translations/uk.json — add Ukrainian translation
• app/translations/ru.json — add Russian translation
• app/translations/pt.json — add Portuguese translation
• app/translations/ja.json — add Japanese translation
• app/translations/pl.json — add Polish translation
• app/routes/password_reset.py (optional) — change not_found to a generic "if account exists" message

Test plan

• tests/e2e/auth/test_login.py — add a test that submits a non-existent username and verifies the error message is identical to the "wrong password" message (not "User not found")
• tests/e2e/auth/test_login.py::TestLoginErrorMessages — existing error message tests should be updated to expect the new generic message
• Verify all 12 translation files contain the new key with appropriate translations

Risks & edge cases

• Auth/security: This is a pure UX hardening change — no functional auth logic changes. Risk is minimal.
• Existing tests: Any tests that assert "User not found" or "Wrong password" as exact strings will need updating.
• Translation completeness: All 12 locale files must be updated or flash_message() will raise a KeyError for the missing key.
• Password reset: If the optional password reset change is made, ensure the message still conveys useful information to legitimate users (i.e., doesn't silently fail with no feedback).

Out of scope

• Rate limiting login attempts (would be a separate mitigation layer)
• Adding CAPTCHA to login (separate feature)
• Changing the authentication mechanism (e.g., switching from username to email)
• Modifying the password reset flow's core logic (only the error message)