Disabling 2FA leaves old backup codes valid forever

Nobody has started this yet — be first.

Business impact

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.

Problem

disable_2fa() clears user.totp_secret and sets totp_enabled = False, but the line that used to delete the user's BackupCode rows is gone -- those rows (hashed, but matched by consume_backup_code() against user_id alone, with no dependency on or ) are left untouched.

Current behavior

Calling consume_backup_code(user_id, "<old backup code>") after 2FA has been disabled still returns True instead of False.

Expected behavior

Disabling 2FA invalidates every backup code the user had, exactly like it invalidates the TOTP secret. If 2FA is re-enabled later, backup codes issued under the previous enablement must never work again.

Steps to reproduce

Enable 2FA, note one of the returned backup codes.
POST /auth/2fa/disable with valid re-proof.
Attempt to consume the noted backup code via consume_backup_code(user_id, code).
Observe: returns True. Expected: False.

Why this matters

This is exactly the class of bug where a state transition (2FA on -> off) that is supposed to be a hard reset left one piece of related state (the backup codes) untouched, and nothing about the rest of the system notices, because consume_backup_code() has no way to know 2FA was ever disabled -- it just checks used_at is None.

Suggested approach

Compare disable_2fa() against confirm_2fa(), which is the function that creates backup codes in the first place, and against the regenerate-backup-codes ticket's stub, which has the same "invalidate the old set" requirement. All three functions care about the same invariant: a user should never have a live BackupCode row that does not correspond to their current 2FA enrollment.

Acceptance criteria

After POST /auth/2fa/disable succeeds, every backup code issued to that user stops working
This holds using either password or TOTP-code re-proof to disable

Verification

pytest practice_tickets/tests/test_ticket_09.py -v

Hints (0/2)

Try it without hints first — the reading is the exercise.

Working on this ticket

Work on a branch named for the ticket — that's what you'll submit.

Branch off your fork

$git checkout -b fix/disable-2fa-backup-codes

Fix it and commit

Meet every acceptance criterion, and add a test that would have caught this.

Push the branch

$git push -u origin fix/disable-2fa-backup-codes

Submit it below

Paste your fork URL and the branch name, with a short write-up of the root cause.

Submit your fix

Questions

Stuck on something?

Ask about anything unclear in the ticket — the maintainer and anyone who has solved it can answer. Please don't post full solutions.

No questions yet. If something in this ticket reads ambiguously, you are probably not the only one — ask.

The project

Production-Style Flask Auth Service

A from-scratch Flask authentication service: JWT access + refresh tokens with rotation and reuse detection, real session/device revocation, password reset, email verification, and TOTP 2FA with backup codes.

Fork on GitHub

Download

Setup

Production-Style Flask Auth Service

git clone <your-fork>
cd FlaskDevTraining/flask_auth_service
cp .env.example .env
make docker-up   # docker compose up --build: Postgres + Redis + Flask dev server

Migrations run automatically on container start. The app is reachable at . Seed two demo users (one plain, one with 2FA already enabled) with -- it prints the 2FA user's TOTP secret, provisioning URI, and a one-liner to compute a current code with , so the 2FA flow is fully testable without an authenticator app. A production-style path with gunicorn (no dev server, no bind mount) is available via .