Fix/disable hashed factorkey

[ieow]

Motivation and Context

Jira Link:

Description

Fix disableHashedFactorkey feature
device factorkey is not set when disableHashedFactoryKey flag is set.
this is causing user lose the device factorkey during signup.
reinitialization - save deviceFactorkey on device if available

Fix atomic sync for
backupMetadataShare
deleteMetadataShareBackup

Add checking for already log-in state in the beginning of loginWithJWT to prevent double login

Add checking for valid factor key during InputFactorKey via Metadata's FactorEncs instead of depend only on checking for metadata linking

update tests
update tests cases

How has this been tested?

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• My code follows the code style of this project. (run lint)
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.
• My code requires a db migration.

---

Note

Harden login and factor handling, persist device factor for disableHashedFactorKey users, wrap metadata updates in atomic sync, and update/add tests (incl. new disableHashedFactorKey flows).

• Core (src/mpcCoreKit.ts):
  • Enforce no double-login by rejecting loginWithOAuth/JWT if already logged in/rehydrated.
  • Validate inputFactorKey against metadata.factorEncs before accepting a factor; reconstruct and finalize accordingly.
  • When disableHashedFactorKey is enabled:
    • Persist device factor locally on signup and on session rehydration if missing.
    • Remove hashed factor backup deletion during MFA enable flow.
  • Wrap backupMetadataShare and deleteMetadataShareBackup in atomicSync for consistent metadata syncing.
  • Improve metadata checks using KEY_NOT_FOUND and SHARE_DELETED constants; minor log message tweak on rehydration failure.
• Tests:
  • Add login-disableHashedFactorKey.spec.ts covering device factor persistence, signing, wallet indices, and pre-sign hooks.
  • Broaden factor, login, gating, session time, ed25519, import/recovery, and SFA import tests:
    • Pass manualSync to critical reset paths; standardize init flags; optionally disable session manager.
    • Add signing helpers and assertions; adjust test emails; verify SFA key cleared post-import.

^{Written by Cursor Bugbot for commit ef5be4c. This will update automatically on new commits. Configure here.}

[himanshuchawla009]

this PR changes a lot of other things which are not well documented in PR description. Please describe the reasoning behind the changes for better review.

[himanshuchawla009]

new wht?

[cursor]

Bug: Double Login Vulnerability in JWT Authentication

The loginWithJWT method is missing the double-login prevention check that was added to loginWithOAuth. According to the PR description, both login methods should check if this.state.factorKey exists to prevent double login, but only loginWithOAuth has this guard. This allows users to call loginWithJWT multiple times or after already being logged in, potentially causing state corruption.

src/mpcCoreKit.ts#L404-L415

mpc-core-kit/src/mpcCoreKit.ts

Lines 404 to 415 in 5d11a85

	public async loginWithJWT(params: JWTLoginParams): Promise<void> {
	this.checkReady();
	const { prefetchTssPublicKeys = 1 } = params;
	if (prefetchTssPublicKeys > 3) {
	throw CoreKitError.prefetchValueExceeded(`The prefetch value '${prefetchTssPublicKeys}' exceeds the maximum allowed limit of 3.`);
	}
	const { verifier, verifierId, idToken, importTssKey, registerExistingSFAKey } = params;
	this.torusSp.verifierName = verifier;
	this.torusSp.verifierId = verifierId;

 

---