2FA - Reopening setup regenerates the secret and invalidates authenticator codes

[luacmartins]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: Not specified in the follow-up report.
Reproducible in staging?: Needs confirmation.
Reproducible in production?: Reported from customer setup attempts; not independently reproduced for this issue.
If this was caught during regression testing, add the test name, ID and link from BrowserStack: Not provided.
Email or phone of affected tester (no customers): Not provided.
Logs: The source report summarizes a September 10 Toggle/Validate failure loop; see Additional Context.
Expensify/Expensify Issue URL: Not specified in the source comment.
Issue reported by: @neerajbachani and team.
Slack conversation (hyperlinked to channel name): Not provided for this case.

Action Performed:

Precondition: The user is setting up 2FA and has not completed validation.

1. Start 2FA setup.
2. Scan the displayed QR code into an authenticator app.
3. Exit the setup page before completing setup.
4. Reopen the setup page.
5. Enter a current code from the authenticator entry created in step 2.

Expected Result:

Returning to an in-progress setup preserves its secret. Codes generated from the QR code already scanned remain valid, allowing the user to finish setup.

Actual Result:

The app repeatedly displays Invalid code. Reopening or refocusing the codes page can issue another Toggle request, generating a different server-side secret while the authenticator still uses the previously scanned one.

Workaround:

No confirmed workaround is documented for this specific case in the source report.

Additional Context:

Split from problem 3 in the follow-up report on #91985.

The report describes this September 10 sequence:

Toggle(200) → Validate(401) ×6 → Toggle(200, NEW secret) → Validate(401) → Toggle(200)

The reported trigger is DynamicTwoFactorAuthPage.tsx, which calls Toggle when the page opens or receives focus without codes in storage. Suggested fix: initialize once per setup and reuse the in-progress secret when returning to that setup.

Regression coverage should verify successful validation after leaving/reopening or refocusing an unfinished setup, no unintended repeated Toggle requests, and correct initialization for a genuinely new setup.

Platforms:

The follow-up report does not specify the exact reproduced platforms.

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

None attached to this case in the source report.

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022104997594808312814
• Upwork Job ID: 2104997594808312814
• Last Price Increase: 2026-09-29

Issue Owner

Current Issue Owner: @neerajbachani

[MelvinBot]

Proposal

What is the root cause of that problem?

Leaving an unfinished setup wipes the setup data from Onyx. Reopening the page then sees no codes and calls Toggle again, so the server creates a new secret.

1. Every exit path clears recoveryCodes and twoFactorAuthSecretKey:
   • The back button calls quitAndNavigateBack → clearTwoFactorAuthData (TwoFactorAuthActions.ts:13-29).
   • Closing the RHP runs clearTwoFactorAuthData(true) in beforeRemove, which also clears twoFactorAuthSetupInProgress (RightModalNavigator.tsx:319-323).
2. On reopen, DynamicTwoFactorAuthPage calls toggleTwoFactorAuth(true) whenever account.recoveryCodes is empty (DynamicTwoFactorAuthPage.tsx:87-95).
3. That call sends EnableTwoFactorAuth with no parameters (Session/index.ts:1416-1418). The server returns a new secret and new recovery codes. The authenticator entry from the first QR code no longer matches, so every Validate returns 401.

This matches the reported Toggle → Validate(401) ×6 → Toggle (new secret) → Validate(401) loop.

Refocusing the page alone does not call Toggle while codes are in Onyx. The repeat call happens only after an exit has cleared them.

What changes do you think we should make in order to solve the problem?

Keep the in-progress setup data until setup ends:

1. In clearTwoFactorAuthData, keep recoveryCodes, twoFactorAuthSecretKey, and codesAreCopied while setup is unfinished.
2. In the RHP beforeRemove listener, stop clearing an unfinished setup.
3. Clear the data only on these events:
   • Setup succeeds. validateTwoFactorAuth already clears the secret, and DynamicSuccessPage clears the rest.
   • 2FA is disabled.
   • The user explicitly restarts setup.
4. DynamicTwoFactorAuthPage already skips Toggle when recoveryCodes exist. No other change is needed there.

Tests to add:

• Leave and reopen an unfinished setup: the same secret is shown, a code from it validates, and Toggle is not called again.
• Start a fresh setup: Toggle is called exactly once.

What alternative solutions did you explore? (Optional)

• Make the server reuse a pending secret. EnableTwoFactorAuth could return the existing unvalidated secret instead of creating a new one. This also covers reopening on another device or after signing out, which the App-only fix does not. That change is outside the App repo, so an internal engineer would need to make it.
• Show a "restart setup" warning before calling Toggle again. This avoids silent invalidation but still makes the user rescan the QR code.

Investigation notes

• Confidence: medium. The mechanism is supported by the code above. I did not reproduce it in the app or check production logs.
• Side effect: each repeat Toggle also creates new recovery codes, so codes the user already downloaded become invalid too. The fix above prevents this for the same device.
• Tradeoff: this keeps the secret in local Onyx storage longer than today. It is already stored there during setup, but reviewers should confirm this is acceptable.
• The verify page's back button returns to the codes page without clearing data (DynamicVerifyPage.tsx:101). Moving back and forth inside the flow is safe. Only leaving the flow triggers the bug.
• Related: split from [$250] Required 2FA setup screen is unresponsive, blocking new-domain login and account merge (closed). No other open duplicates found.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/102575) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

---

view run

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @Ollyws (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022104997594808312814

[neerajbachani]

@luacmartins hey!!

[bonnhatnguyen]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Reopening an in-progress 2FA setup flow regenerates the secret key and recovery codes, which invalidates any TOTP codes generated by authenticator apps that scanned the initial QR code. As a result, code validation repeatedly fails with 401.

What is the root cause of that problem?

1. In TwoFactorAuthActions.ts:16-24, exiting the 2FA setup flow calls clearTwoFactorAuthData():
   • When tapping Back, quitAndNavigateBack triggers clearTwoFactorAuthData().
   • When closing the RHP modal, beforeRemove in RightModalNavigator.tsx:319-323 calls clearTwoFactorAuthData(true).
     Both paths set recoveryCodes: null and twoFactorAuthSecretKey: null in ONYXKEYS.ACCOUNT.
2. When the user returns to the 2FA setup page, DynamicTwoFactorAuthPage.tsx:87-95 checks:

   if (isLoadingOnyxValue(accountMetadata) || (is2FAEnabled && !is2FASetupInProgress) || account?.recoveryCodes || !isUserValidated) {
       return;
   }
   toggleTwoFactorAuth(true);

3. Because account?.recoveryCodes was wiped to null, toggleTwoFactorAuth(true) is called again.
4. Calling toggleTwoFactorAuth(true) triggers the EnableTwoFactorAuth API request, causing the backend to regenerate a fresh secret key and a new set of recovery codes.
5. Any authenticator entry configured from the first QR code/secret now mismatches the new server secret, causing every subsequent validateTwoFactorAuth attempt to fail with 401.

What changes do you think we should make in order to solve the problem?

Preserve the in-progress 2FA setup credentials in Onyx until the setup is explicitly completed, disabled, or reset:

1. In src/libs/actions/TwoFactorAuthActions.ts:
   Modify clearTwoFactorAuthData so that when twoFactorAuthSetupInProgress is true (or unless forceClear = true), it does not prematurely wipe twoFactorAuthSecretKey, recoveryCodes, and codesAreCopied.
2. In RightModalNavigator.tsx (beforeRemove for 2FA screens):
   Do not wipe the in-progress setup credentials on modal dismissal.
3. Clean up the setup data only on lifecycle completion points:
   • Successful validation in DynamicSuccessPage / validateTwoFactorAuth.
   • Explicit 2FA disablement.
   • Or when the user explicitly clicks a "Restart setup" action.
4. Since DynamicTwoFactorAuthPage already guards against calling toggleTwoFactorAuth(true) when account?.recoveryCodes exists, keeping the codes in Onyx ensures returning to the screen reuses the existing secret without triggering duplicate EnableTwoFactorAuth requests.

What alternative solutions did you explore? (Optional)

Handling secret reuse entirely on the backend in EnableTwoFactorAuth (returning an existing pending unvalidated secret if setup is already in progress). However, retaining the client-side Onyx state ensures consistent offline resilience and avoids redundant network calls.

[neerajbachani]

@Ollyws This issue is coming from the additional problems I found during the investigation on #91985, summarized here: #91985 (comment)

I’ll take care of this and proceed with the fixes. Please assign this to me as per @luacmartins comment here #91985 (comment)

[melvin-bot]

📣 @neerajbachani You have been assigned to this job!
Please apply to the Upwork job and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑‍💻
Once you apply to this job, your Upwork ID will be stored and you will be automatically hired for future jobs!
Keep in mind: Code of Conduct | Contributing 📖