[nimish-ks]

Passkeys (WebAuthn) as a second factor, alongside or instead of TOTP.

What users get

• Add a hardware security key (YubiKey, Titan, …), a device passkey (Touch ID, Windows Hello) or a password-manager passkey (Bitwarden, 1Password, iCloud Keychain, Google Password Manager). After the browser prompt, a review step shows the detected provider and an editable name.
• One shared set of recovery codes: issued with the first factor, deleted with the last.
• Sign-in offers every method the account has (passkey, authenticator app, recovery code) on a redesigned second-factor screen. /login/mfa with nothing pending redirects to /login.
• Passkey details (stored metadata as JSON), removal, and method tabs for every "confirm it's you" proof; TOTP setup is now code step → proof step.

Security

• Every factor change needs proof of a current factor on top of the fresh-session gate; one proof per request.
• Wrong codes lock codes after 10 attempts (counted before checking); passkeys can't be guessed, so they stay usable while codes are locked.
• Signature counters enforced for device-bound keys; challenges single-use, per purpose and user.
• Attestation is requested only so browsers reveal the key model for labels; the statement is never trusted or allowed to fail registration.
• Passkeys are bound to the Console's own domain (first ALLOWED_ORIGINS entry). No new env vars or server secrets.
• Security emails say whether 2FA is still on; session recordings never capture network bodies.

Testing

• Backend: new test_passkeys.py plus updated MFA tests (172 in the 2FA suites); full suite passes apart from the 5 tests that fail on main in the dev container.
• Frontend: jest 516/516, tsc and lint clean.
• Browser QA with Chromium virtual authenticators (sign-in, add/remove, lost responses, lockouts), Bitwarden against a local Vaultwarden, and WebKit.

Docs: phasehq/docs#274