Production-Style Flask Auth Service

Login rate limit trips one attempt before its configured limit

Ops sets `LOGIN_ACCOUNT_LIMIT=5` expecting customers get 5 login attempts per window before being throttled. In reality they get 4. This kind of silent, invisible-in-the-dashboard gap between "what ops configured" and "what the system actually enforces" causes exactly the kind of confusing false-positive lockout complaints that eat on-call and support time disproportionately to how serious the underlying bug looks in a diff.

Retry-After header reports the wrong (too-short) cooldown

`Retry-After` is the contract a rate limiter makes with well-behaved clients: "back off for this long, then it is safe to try again." A client that honors the header and gets told `Retry-After: 0` will retry immediately -- and get another 429 -- potentially forever, in a tight loop. A rate limiter that lies about its own cooldown does not protect anything; it just adds a confusing, self-defeating layer of latency on top of whatever abuse it failed to stop.

Add POST /auth/2fa/backup-codes/regenerate

Right now, a user's only way to get a fresh set of backup codes is to fully disable and re-enable 2FA -- a clunky, alarming flow. Support gets tickets from users who have used most of their codes, or suspect one leaked, and want to rotate them without touching whether 2FA is on at all. This is a standard capability in any product with recovery codes (GitHub, Google, etc. all offer "regenerate codes" as a first-class action).

Password-reset and verification emails sent unencrypted in production

Every password-reset token and email-verification token this service issues is single-use but still a live credential for up to 24 hours or 30 minutes. Sending them over an unencrypted SMTP connection means anyone positioned on the network path between this app and the mail server can read them in plaintext and take over the account before the legitimate user even opens their inbox. This is also the kind of finding that fails a SOC 2 / PCI audit outright and can block enterprise deals.

TOTP codes from the last step of the valid window are rejected

`TOTP_VALID_WINDOW` exists specifically to tolerate small clock drift between a user's phone and the server, and the couple of seconds it takes a human to read a 6-digit code and type it in before it rotates. The direction that matters most in practice is "the code the user is looking at is about to roll over to the next one" -- the +1 step. Users whose phone clock runs even slightly fast, or who are a beat slow entering a code near a 30-second boundary, get a confusing, intermittent "invalid code" on a security-critical login path.

"Remember me" on login

Currently `POST /auth/login` silently ignores any `remember_me` field in the request body -- every session gets a refresh token good for `REFRESH_TOKEN_TTL_DAYS` (30 days by default), no matter what the client asks for. `REMEMBER_ME_REFRESH_TOKEN_TTL_DAYS` (180 days by default) already exists in config but nothing reads it, so there is no way for a client to ask for a longer-lived session on a trusted device.

Disabling 2FA leaves old backup codes valid forever

A user's mental model of "I disabled 2FA" includes an implicit assumption: any recovery code they wrote down, screenshotted, pasted into a support ticket, or had seen by someone else along the way is now dead. That assumption is false. Anyone holding an old code -- an ex-employee with access to an old support thread, someone who found a screenshot, a family member who saw it once -- can use it to pass a 2FA challenge on an account whose owner believes they have rotated past it entirely. This is a stale-credential exposure that is invisible in every normal usage of the product.

Account lockout after consecutive failed logins

This is a distinct defense-in-depth control from the rate limiting already implemented: rate limiting counts requests in a rolling window and resets on its own regardless of outcome. Lockout should count consecutive failures and reset immediately to zero the moment a login succeeds -- so a legitimate user who fat-fingers their password twice is never penalized, while a sustained guessing attempt, even one paced slowly enough to stay under the rate limit, still gets cut off.

Any authenticated user can revoke any other user's session (IDOR)

Any authenticated user -- a free account, a trial signup, anyone who can create an account at all -- can forcibly log out ANY other user's device at will, with no relationship to that account required, just knowledge of a `family_id`. At minimum this is a denial-of-service tool against specific targets; combined with any way to learn or enumerate `family_id` values it becomes a targeted account-disruption vector. This is a textbook IDOR (insecure direct object reference) -- the class of vulnerability where an object identifier alone, with no ownership check, is treated as sufficient authorization.

Security-sensitive actions leave no audit trail

A fully-built extension point (`SecurityEventLogger` / `NullSecurityEventLogger` / `RecordingSecurityEventLogger`, wired into `create_app()` via `AuditExtension.init_app()`, built on the exact same pattern as `MailerExtension` in `email.py`) already proves itself at one call site: `login()` already calls `audit.log("login_success", ...)` and `audit.log("login_failed", ...)`. But `password_reset_confirm()`, `disable_2fa()`, and `revoke_all_sessions()` -- each at least as security-relevant as a login attempt -- call it nowhere at all, leaving incident response and compliance with no record of these actions.

Concurrent refresh-token rotation forks a session into two live branches

The entire security pitch of refresh-token rotation rests on "exactly one refresh token is ever valid at a time per session." If two requests presenting the same refresh token can both succeed -- which a flaky mobile client silently retrying a slow request, a misbehaving proxy replaying a request, or a genuine attacker racing a legitimate client can all trigger -- the system silently ends up with two live, independent refresh-token chains descending from one login, with no record anywhere that this happened and no alert.

Configurable TOTP code length is only half-wired

`TOTP_DIGITS` (default 6, the RFC 6238 / Google Authenticator default) already exists in config, and `provisioning_uri()` already reads it correctly when telling an authenticator app how many digits to generate. But `verify_totp_code()` never reads it, so any deployment that changes `TOTP_DIGITS` away from 6 gets a 2FA flow where the provisioning side and the verification side disagree about the protocol they are speaking.

Refresh-token reuse no longer kills the session family

This is the single most important security property in the entire service: if a refresh token is ever stolen, the system's only way of noticing is that the legitimate client eventually presents the token too, after the thief has already used (and rotated) it. That replay is supposed to be treated as a full compromise signal and kill every token in the session family, forcing a real re-login. Right now it does not: an attacker who steals a refresh token and rotates it once keeps a fully working, never-flagged session indefinitely -- the exact scenario this whole project's headline feature was built to prevent is currently silently disabled.