[security-sensitive] 2FA re-enrollment rotates the TOTP secret in place and keeps verified=1 (integrity/availability)

[baozhoutao]

Surfaced by QA run #10663 (identity-auth.two-factor-verify-to-activate / -enrollment-reveal) at 79ebb37. Existence + mechanism only; full reproduction withheld pending maintainer review per the auth/authz disclosure carve-out — available in the QA session on request.

What

Calling POST /api/v1/auth/two-factor/enable while 2FA is already active rotates the stored TOTP secret in place on the same sys_two_factor row and leaves verified = 1 carried over from the prior enrollment. The replacement secret — which no code has ever confirmed — becomes immediately live at the sign-in challenge, while the previously verified secret goes dead. Not a privilege escalation (the call requires a live session and the account password, and such an actor could call /two-factor/disable anyway).

Impact

• Integrity of the flag: verified no longer describes the secret actually stored — any code or audit trusting "this factor was user-confirmed" is wrong after a re-enroll.
• Availability: a user who re-enrolls and mis-scans the QR is locked out instantly — the old authenticator is already dead and there is no confirmation step to catch it.

Mechanism (fix-oriented)

The enable path treats an already-enrolled account the same as a fresh one, overwriting the secret without resetting verified to false or requiring a re-verification before the new secret is honored at the challenge. Fix direction: on re-enroll, set verified = false and gate the new secret on a fresh verify (or reject enable when already enabled and route through a dedicated rotate flow).

Related

Same family: sys_user.generate_backup_codes silently re-provisions on an already-enabled account too (see the non-sensitive lockout card #10681).

QA-source: #10663 · identity-auth.two-factor-verify-to-activate · clause 2 / negative 1

[os-zhuang]

Triage: lands in packages/plugins/plugin-auth (2FA enable path) ⇒ pm:queue · domain:services · type Bug. Rationale: verified = 1 describing a secret no one ever confirmed violates the flag's declared meaning — invariant restoration, no ruling needed to queue it.

Dispatch notes for the executing seat:

• Fix route is constrained: take the minimal invariant-restoring route — on re-enroll, reset verified = false and gate the new secret behind a fresh verify. The alternative in the card (reject enable when already enabled + a dedicated rotate flow) adds new public surface and is NOT to be taken without a maintainer ruling.
• Clause-② expected yes: the change alters accept/verify behavior of a published auth endpoint (enable-while-enrolled currently hot-swaps the live secret; after the fix the new secret is inert until verified). Contract-review tier applies at dispatch per clause ②.
• Reproduction is withheld in the card by the disclosure carve-out — the QA session (QA run · scan-functionality 14-item scope · 7 pass / 7 fail (14/14 adjudicated) · 79ebb37 · 2026-08-21 #10663) has it; the dev should reproduce locally from the mechanism description, not ask for the withheld repro on-thread.
• Related family: 2FA backup-code regeneration on the navigable surface is a lockout path (sys_user.generate_backup_codes has no resultDialog) #10681 (generate_backup_codes silent re-provision) — same shape, different endpoint; keep surfaces separate unless the family-dispatch five gates are answered.

Size/model suggestion: M, opus floor; clause-② review at the contract tier.

---

Generated by Claude Code

[os-warren]

Claim: dispatched.

• session: user-29 [974948]
• branch: claude/issue-10700-2fa-reenroll-verified-flag
• worktree: ../objectstack-10700
• Clause-②: YES — this changes the accept/reject behaviour of a published auth endpoint. Develop at claude-opus-5 (this seat's CONTRACT_REVIEW_TIER allocation is exhausted; the constant reads claude-fable-5 at scripts/pm/dispatch-gates.mjs:1932). PR stays draft and needs:contract-review is hung on this card as the compensating control. ⛔ This seat does not clear that label — only a non-dispatching seat may, after a PASS.
• serial constraint: plugin-auth two-factor surface. Free — fix(plugin-auth): a 2FA verification echoes the session it installed, not the one it deleted #10954 ([security-sensitive] 2FA verify-totp token is not accepted on the bearer seam and overrides a valid cookie (fail-closed lockout) #10701) merged at 01:45Z. ⚠️ 2FA backup-code regeneration on the navigable surface is a lockout path (sys_user.generate_backup_codes has no resultDialog) #10681 is the same family (generate_backup_codes re-provisioning on an already-enabled account) and is deliberately not dispatched alongside this; it waits for this to land.

Direction

The defect is proven and the card states it: POST /two-factor/enable on an already-active account rotates the stored TOTP secret in place and carries verified = 1 over from the prior enrollment, so verified stops describing the secret actually stored, and a mis-scanned re-enroll is an instant lockout with no confirmation step.

This is a tightening, which is why it is dispatchable at all — a permission-boundary loosening would be a maintainer floor. Nothing here may widen what the endpoint accepts.

The design call is NOT yours to make silently

The card names two remedies and they are not equivalent:

1. on re-enroll set verified = false and gate the new secret on a fresh verify before the challenge honours it;
2. reject enable when already enabled, and route rotation through a dedicated flow.

(2) removes a currently-working call from a published endpoint; (1) does not. Measure both, implement the one the measurements support, and if the evidence does not separate them, report needs_decision with what you measured rather than picking. Filling in a verdict you do not believe is the failure this lane refuses — #10660's dev declined to pick a ledger disposition for exactly that reason and was upheld.

What must be pinned — both directions

• The old secret must be dead only when the new one is live and confirmed; pin the window explicitly.
• verified must describe the stored secret at every point in the flow. Assert the flag AND the challenge outcome — the flag alone is what went wrong here.
• Still-works legs are load-bearing: a first-time enrollment must still complete, and a legitimate rotation must still be possible. An implementation that refuses every enable would pass a one-directional suite and break every new enrollment shipping today.
• Assertions end at what does the next sign-in challenge accept, never at status alone — ADR-0112, code and status.

⛔ Disclosure discipline — binding

Auth/authz carve-out. The full reproduction stays in QA session #10663. No reproduction recipe in the PR body, this card, any commit message or comment — not the request sequence, not the seeding steps. Report mechanism and verdict, not the route. Need the withheld detail? Ask on #10663; do not reconstruct and publish it.

Refs

QA #10663 (parent, holds the withheld reproduction) · #10681 (same family, held back) · #10701 / PR #10954 (freed this surface) · ADR-0112

---

Generated by Claude Code