CWE-307: Weak password reset (4-digit code, no rate limiting)

[DogukanUrker]

Security Issue: CWE-307 - Weak Password Reset Mechanism

Severity: High
CVSS: 7.5

Description

The password reset functionality uses a 4-digit numeric code (1000-9999), providing only 9000 possible combinations. There is no rate limiting on password reset attempts.

Attack Vector

An attacker can brute-force the password reset code in real-time with no account lockout or rate limiting.

Fix Required

1. Increase code length to at least 6 digits (1,000,000 possibilities)
2. Implement rate limiting (e.g., max 3 attempts per 15 minutes)
3. Add exponential backoff after failed attempts
4. Consider implementing password reset via secure link instead of numeric code

References

• CWE-307: Improper restriction of unlimited authentication attempts

[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

The password reset flow (app/routes/password_reset.py:29-182) uses a 4-digit numeric code (1000-9999) with no rate limiting, no code expiration, and no timing-safe comparison. An attacker can brute-force the code in real-time from any IP with no account lockout.

Specific vulnerabilities:

• app/routes/password_reset.py:128 — randint(1000, 9999) produces only 9000 possible codes.
• app/routes/password_reset.py:55 — code == password_reset_codes_storage.get(username, "") uses plain Python string comparison, leaking timing information about how many digits matched.
• app/routes/password_reset.py:26 — password_reset_codes_storage = {} is an in-memory dict with no TTL; codes persist until consumed or the server restarts, enabling replay attacks.
• app/utils/forms/password_reset_form.py:31 — validators.Length(min=4, max=4) hard-codes 4-character input, preventing any increase in code length.
• No rate limiting, no attempt tracking, no exponential backoff anywhere in the app.

Current state in main

• Code is still 4 digits, generated via random.randint(1000, 9999) at app/routes/password_reset.py:128.
• app/utils/route_guards.py exists with login_required and admin_required decorators, but no rate-limiting decorator exists.
• No flask-limiter, slowapi, or any rate-limiting library is installed (confirmed by searching for flask_limiter, throttle, rate_limit — zero matches).
• The form validator enforces exactly 4 characters (app/utils/forms/password_reset_form.py:31).
• The password reset route is publicly accessible (no @login_required or @admin_required on it).
• The code is stored in a module-level dict with no expiration.

Root cause

The password reset mechanism was designed as a simple numeric PIN without considering that:

1. 4 digits = 9000 possibilities is trivially brute-forceable over HTTP (no rate limiting means an attacker can try all codes in seconds).
2. Plain string == comparison on the code leaks timing side-channel info about correct prefixes.
3. No expiration means a leaked code can be replayed indefinitely.

Proposed fix

1. Increase code length to 6 digits

• Change randint(1000, 9999) to randint(100000, 999999) at app/routes/password_reset.py:128.
• Update form validator at app/utils/forms/password_reset_form.py:31 from Length(min=4, max=4) to Length(min=6, max=6).

2. Add code expiration (15 minutes)

• Change the storage from a flat dict to a dict of dicts: {"username": {"code": "...", "expires_at": <unix_ts>}}.
• On code generation (password_reset.py:129), set expires_at = time.time() + 900.
• On code verification (password_reset.py:55), check expires_at before comparing; if expired, treat as wrong code and delete the entry.

3. Implement rate limiting on the reset attempt endpoint

• Add a per-username attempt tracker in the same storage dict: {"username": {"code": "...", "expires_at": ..., "attempts": 0, "last_attempt": 0}}.
• After 3 failed attempts within 15 minutes, lock the username for 15 minutes (return a generic "try again later" message instead of "wrong code").
• After each failed attempt, reset the window (sliding window of 15 min).

4. Use timing-safe comparison for the code

• Import hmac.compare_digest (stdlib, no new deps).
• Replace code == password_reset_codes_storage.get(...) with hmac.compare_digest(code, stored_code).

5. Add a rate-limit decorator to route_guards.py

• Create @rate_limit_per_user(max_attempts=3, window_seconds=900) in app/utils/route_guards.py.
• Track attempts in-memory (same dict pattern as password_reset_codes_storage, or a shared rate_limits dict).
• Apply it to the POST endpoint for code_sent=true (the verification endpoint).

6. Improve error messages

• Replace "wrong" code message with a generic "Invalid code. Please try again." to avoid leaking whether the code format was wrong vs the code was incorrect.
• Add a new flash message key for "too many attempts, try again later".

Files to change

• app/routes/password_reset.py — code generation (6 digits), expiration check, timing-safe compare, attempt tracking, lockout logic
• app/utils/forms/password_reset_form.py:31 — change code field validator from Length(min=4, max=4) to Length(min=6, max=6)
• app/utils/route_guards.py — add rate_limit_per_user decorator
• app/translations/*.json — add translation keys for new flash messages (optional, can use existing "wrong" key)

Test plan

• Unit test: Verify 6-digit code generation range (randint(100000, 999999)).
• Unit test: Verify code expiration — set expires_at to past, confirm verification fails.
• Unit test: Verify lockout — 3 failed attempts within 15 min window triggers lockout; 4th attempt returns lockout message.
• Unit test: Verify timing-safe comparison — hmac.compare_digest does not short-circuit on partial match (this is a property of the stdlib function).
• E2E test: tests/e2e/pages/login_page.py:21 references the password reset flow — add/extend E2E test to verify 6-digit code entry and lockout behavior.
• Reference existing tests: tests/e2e/ — check for any existing password_reset test files.

Risks & edge cases

• Race conditions: The in-memory dict is not thread-safe. If the app runs with multiple workers (gunicorn), rate limits and codes won't be shared. Consider a threaded lock or moving to Redis for production. For the current single-process setup, a threading.Lock around the dict is sufficient.
• Email enumeration: The current flow reveals whether a username+email pair exists. This is a separate issue (CWE-204) and is out of scope here, but worth noting.
• Existing codes: After deployment, old 4-digit codes in memory become invalid (format mismatch on length validation). This is a clean break with no migration needed.
• SMTP dependency: The fix does not change the SMTP flow, but if SMTP is misconfigured, the rate limiter should still apply to the POST endpoint to prevent abuse of the "code sent" flow.
• Memory growth: The storage dict grows with each request. Add a cleanup task (e.g., on each request, purge entries older than 30 minutes) to prevent unbounded growth.

Out of scope

• Switching to secure-link-based password reset (email with signed URL) — this is a larger architectural change.
• Adding CSRF protection to the password reset form (separate concern, though recommended).
• Adding reCAPTCHA or hCaptcha to the forgot-password page.
• Email enumeration prevention (CWE-204).
• Database-level audit logging of password reset attempts.