fix(onboarding): recovery phrase corruption via PIN mismatch#339
Merged
fix(onboarding): recovery phrase corruption via PIN mismatch#339
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
When a user taps "Create Account", sets PIN A, and proceeds to cloud backup setup, the account is created with secrets encrypted using PIN A. If the user then navigates back to Welcome (e.g. backup setup fails) and taps "Create Account" again, they go through
PincodeSeta second time and can set a different PIN B. The oldgetOrCreateAccount()silently returned the existing account because it found one in Redux state, but PIN B is now cached in memory. All secrets remain encrypted with PIN A. Every subsequent operation that decrypts the mnemonic or private key uses the wrong password leading to corrupted mnemonic readings.Reproduction
Ensure Cloud Backup is enabled.
111112), proceed to cloud backup setup111113)Fix
Instead of relying on whether an account already exists in state, we now rely on user intent. If the user chose "Create Account", we always clean up stale keychain entries and create a fresh account -- regardless of what might be left over from a previous attempt.
If the user chose to restore, we skip account creation entirely, since restore flows (seed phrase import, cloud backup) set up the account themselves before reaching
initializeAccountSaga.Specifically:
web3/saga.ts: RenamedgetOrCreateAccounttocreateAccount, removed the early-return guard, and addedclearStoredAccounts()at the top to wipe orphaned private key entries before creating fresh ones.account/saga.ts: TheinitializeAccountSagachecks choseToRestoreAccount to decide whether to call createAccount.Test plan
Related issues
User feedback: https://clabsco.slack.com/archives/C0A7SBUCQ12/p1770251915898519
Backwards compatibility
Y
Network scalability
NA