Phishing-Resistant MFA Attestation (Plaid Questions 4 and 5)

Our primary second factor is a FIDO2 / WebAuthn passkey. A passkey is a private key held in the secure hardware of the user's device (Secure Enclave, TPM, or a hardware security key) and unlocked by the user with Face ID, a fingerprint, or a device PIN.

Passkeys are phishing-resistant for three structural reasons, not because of user training:

• Origin binding. The browser will only release a signature to the exact registered relying party (our domain). A look-alike phishing domain cannot obtain a usable assertion, even if the user is fully deceived and cooperates.
• No shared secret. There is nothing for a user to read out, type, or paste. The private key never leaves the device and is never transmitted, so it cannot be captured by a fake login page, a proxy, or a screen share.
• Challenge–response with replay protection. Each authentication signs a fresh server-issued, single-use challenge that we bind to the user, mark as spent, and expire after five minutes. A captured assertion cannot be replayed.

Attacker-in-the-middle toolkits that defeat one-time passcodes (Evilginx-class proxies) do not defeat this control, because the assertion they would relay is cryptographically bound to the phishing origin and is rejected by our server.

Every consumer (client) account must complete a passkey challenge before the application renders any screen from which a bank or accounting connection can be started. Plaid Link is surfaced only from inside such a screen, so Link cannot be reached without a completed phishing-resistant check in the current session.

The gate is a two-step sequence and both steps must be satisfied in the current browser session:

1. Step 1 — session assurance. The sign-in session must be elevated to two-factor assurance (AAL2) using a TOTP authenticator code. This protects the sign-in itself.
2. Step 2 — phishing-resistant confirmation. The user must complete a WebAuthn passkey assertion, verified server-side. If the account has no passkey yet, the gate requires enrollment before it will proceed. There is no bypass and no "skip" option.

The following consumer screens sit behind that gate:

• Bank connection and bank file upload — /client/bank-files, the screen from which Plaid Link is launched.
• QuickBooks Online connection — /client/quickbooks, the screen that starts the accounting OAuth flow.
• Sign-in security settings — /client/security, where a consumer manages their own passkeys, authenticator, and backup codes.

The same code path, the same gate, and the same passkey requirement apply on desktop web and on mobile web. There is no separate mobile flow with weaker controls.

The systems that store or process consumer financial data are: the LedgerDude staff workspace, the production PostgreSQL database and file storage, the secret store holding integration credentials, the source repository, the hosting platform, the payment processor, and the Intuit developer account.

• Staff workspace — phishing-resistant, mandatory, no opt-out. The entire staff portal is wrapped in a guard that renders nothing until the staff member has both an AAL2 session and a verified WebAuthn passkey assertion in the current session. Staff can reach every client's books, so the whole portal is gated, not only the connection screens. Staff cannot disable either factor.
• Sensitive client connection screens. Staff acting inside a client workspace, including staff preview of the client portal, pass the same passkey gate that consumers pass.
• Database, storage, and secret store. There is no shared server login and no standing console access. Administrative access is held by the Security Officer on an account protected by the provider's MFA, with a hardware-backed factor where the provider supports it.
• Source repository, hosting, payments, Intuit developer. Each vendor console is protected by that provider's MFA on the owner account. Passwords are checked against known-breached password lists.
• Automated/service access. Machine-to-machine access uses scoped credentials held in managed secret storage, never interactive logins, and is therefore not phishable.

• Standard: W3C Web Authentication (WebAuthn Level 2) with FIDO2 CTAP authenticators. Attestation type none; resident key preferred.
• User verification: required — userVerification: "required" on both registration and authentication, so the biometric or PIN check is always performed on the device. Possession alone is not sufficient.
• Relying party binding: the relying party ID and expected origin are derived server-side from the request and enforced on verification. An assertion produced for any other origin is rejected.
• Challenges: generated server-side, stored server-side, scoped to one user and one purpose, single-use, and expired after five minutes.
• Credential storage: only the credential ID and the public key are stored. No private key material and no shared secret ever reaches our servers. The signature counter is persisted and advanced on every use to detect cloned authenticators.
• Verification: performed entirely server-side. The browser cannot assert its own success; the client receives access only after the server records a valid assertion.
• Session scope: a successful assertion is recorded against a one-way hash of the current sign-in session and expires after 12 hours. It cannot be transferred to another session, device, or browser.
• Row-level security: passkey records are readable only by their owner and writable only by server code. Challenge values are not readable from the browser at all.

• Users are encouraged to enroll passkeys on two devices, for example a phone and a laptop. A user cannot delete their only remaining passkey.
• Every account can also hold ten one-time backup recovery codes, stored only as SHA-256 hashes and displayed once at generation. Redeeming a code clears the existing authenticator so a new device can be enrolled.
• Backup codes are a recovery mechanism, not a routine login path, and redeeming one is logged. They do not bypass the passkey gate on bank connection screens: a new passkey must be enrolled before those screens open again.
• Account recovery that cannot be completed with a second passkey or a backup code is handled by the Security Officer at security@myledgerdude.com with identity verification.

SMS one-time codes, email one-time links or codes, security questions, and device cookies are not accepted as a second factor anywhere in the platform. TOTP authenticator codes are used to elevate the sign-in session, but they are never sufficient on their own to reach a bank connection screen, the Plaid Link flow, or the staff workspace — a passkey assertion is always required in addition.

This control is reviewed at least annually by the Security Officer. Changes to the authentication flow, the set of gated screens, or the relying-party configuration are version-controlled, reviewed, and tested before release. Changes that would weaken the phishing-resistant requirement require Security Officer approval and an update to this page.

See the full Information Security Policy for access control, encryption, logging, retention, third-party access, and incident response.