Configurable TOTP code length is only half-wired

Nobody has started this yet — be first.

Business impact

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.

Problem

verify_totp_code() builds its own pyotp.TOTP(secret) with no digits argument at all, silently defaulting to 6 regardless of what TOTP_DIGITS actually says, even though provisioning_uri() two functions away correctly reads current_app.config.get("TOTP_DIGITS", 6).

Current behavior

With TOTP_DIGITS=8 set, an 8-digit code generated exactly as the provisioning URI instructed is rejected by verify_totp_code() as an "invalid code."

Expected behavior

Whatever TOTP_DIGITS is set to, provisioning_uri() and verify_totp_code() agree on it. Setting TOTP_DIGITS=8 (or any other supported length) results in a working 2FA flow end to end: the provisioning URI tells the authenticator app to generate N-digit codes, and the server checks against N-digit codes.

Steps to reproduce

Set TOTP_DIGITS=8 on the app config.
Generate a code with pyotp.TOTP(secret, digits=8) (matching what provisioning_uri() advertises).
POST /auth/2fa/confirm (or /2fa/verify) with this code.
Observe: 400 {"error": "invalid code"} -- expected 200.

Why this matters

This is a cross-component protocol mismatch scoped to a single codebase: the code path that advertises a protocol parameter (digit count) to an external party (the user's authenticator app, which has no other source of truth) and the code path that enforces it are two different functions, edited at two different times. The bug is invisible with the default config (both sides happen to agree by coincidence: 6 is both the hardcoded pyotp default and the configured default), which is exactly what makes this kind of mismatch dangerous -- it passes every test until the day someone actually changes the config value, at which point 2FA silently locks out 100% of users on that deployment.

Suggested approach

Compare the two functions side by side. provisioning_uri() already shows the correct pattern for reading TOTP_DIGITS from current_app.config. Also consider: does changing the digit count change anything else about how verify_totp_code()'s manual step-checking loop needs to work, or is it purely a constructor argument?

Acceptance criteria

With the default config (TOTP_DIGITS=6), nothing changes -- all existing 2FA tests still pass
With TOTP_DIGITS=8 set, a code generated with pyotp.TOTP(secret, digits=8) is accepted by verify_totp_code()
With TOTP_DIGITS=8, a 6-digit code (the old default) is correctly rejected

Verification

pytest practice_tickets/tests/test_ticket_14.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 feat/totp-digits-mismatch

Fix it and commit

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

Push the branch

$git push -u origin feat/totp-digits-mismatch

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 .