A password is a reusable secret. If it is guessed, leaked, reused after another breach, or entered on a convincing fake login page, an attacker may be able to use it from anywhere. Two-factor authentication (2FA) requires a separate proof of identity—usually something the user possesses—so a stolen password alone is not enough.
For an application, 2FA is far more than a screen requesting a six-digit code. It affects the authentication state machine, account recovery, session handling, support procedures, and audit records. It also matters that different second factors offer very different levels of resistance to phishing and account takeover.
What makes authentication “two-factor”?
Authentication factors generally fall into three categories:
- Something the user knows: a password, PIN, or recovery phrase.
- Something the user has: a phone, hardware security key, authenticator app, or securely stored recovery code.
- Something the user is: a biometric check, such as a fingerprint or face scan.
Entering a password twice is still one factor. A password plus a one-time code from an authenticator app is two factors. On a phone, biometrics commonly unlock a private key held by the device; the server verifies the resulting cryptographic response, not the fingerprint itself.
2FA lowers risk, but it does not make an application immune to compromise. Malware on a device, a stolen session cookie, a fraudulent recovery process, or a phishing site that relays codes in real time can still defeat weaker setups. The goal is to reduce those paths, not create a false sense of safety.
Choose factors based on the threat model
Start with what an account can do. An account that stores only a nickname has different consequences from one that can access customer records, administer an organization, change payment details, or create API keys. Higher-impact actions call for phishing-resistant authentication and step-up verification, even after the user has signed in.
| Method | Strengths | Important limitations |
|---|---|---|
| Authenticator app (TOTP) | Works offline, is widely supported, and is inexpensive to deploy | Codes can be phished; the shared secret must be protected |
| Push approval | Simple user experience | Approval fatigue and deceptive prompts are risks; use number matching |
| SMS or voice code | Accessible fallback where apps or keys are unavailable | Susceptible to SIM swaps, message interception, and phishing |
| FIDO2/WebAuthn passkey or security key | Strong phishing resistance; no shared secret is sent to the site | Requires compatible client support and careful account recovery |
| Email code | Easy to add to an existing email flow | Usually protects the account only as well as the email account; weak as a primary second factor |
For new consumer and business applications, WebAuthn passkeys or hardware security keys are strong primary choices. TOTP remains a practical, broadly compatible alternative. SMS may be needed as a restricted recovery or compatibility option, but it should not be presented as equal to a phishing-resistant factor.
Design the enrollment flow carefully
Require a recent password check or an existing strong session before a user can add, remove, or replace an authentication factor. Otherwise, someone who briefly accesses an unlocked session could register their own device and keep access.
Enrollment for TOTP
A time-based one-time password uses a randomly generated secret shared by the application and an authenticator app. The server encodes that secret in a QR code and should also offer a manually entered setup key for accessibility. Before the factor becomes active, the user must enter a newly generated code. This confirms that the app scanned the correct secret and catches common setup errors.
- Create a high-entropy secret with a cryptographically secure random generator.
- Associate it with the authenticated user in a pending state.
- Display the QR code only over HTTPS and only within the authenticated enrollment session.
- Verify a current code from the authenticator app.
- Mark the factor active, create recovery codes, and record an audit event.
Never log the QR payload, TOTP secret, generated codes, or recovery codes. Where possible, encrypt stored TOTP secrets with a server-side key-management system and strictly limit which services and administrators can decrypt them. Hashing alone is insufficient because the server must recover the secret to validate future codes.
Enrollment for WebAuthn
With WebAuthn, the server creates a one-time registration challenge and sends it to the browser. The authenticator creates a key pair, keeps the private key locally, and returns a public credential with signed registration data. Store the credential identifier, public key, user identifier, relying-party information, and relevant signature-counter data. On the server, validate the challenge, expected origin, relying-party ID, and cryptographic signature. Those checks are central to WebAuthn’s phishing resistance.
Model login as a short-lived transaction
After the password is verified, do not issue a fully authenticated session yet. Create a limited, short-lived “2FA pending” transaction tied to the user, intended action, timestamp, and a secure server-side record or signed state token. It should be allowed to submit only the factor-verification request. Once verification succeeds, rotate the session identifier and issue the normal authenticated session.
This separation prevents accidental access to protected endpoints between password verification and second-factor verification. It also makes rate limiting more practical: apply limits per account, IP address, device context, and pending transaction without permanently locking out a legitimate user because of one network.
TOTP verification needs a small allowance for device clock drift, commonly the immediately adjacent time interval. Keep that window narrow and, where feasible, record the last accepted counter or time step to reduce code replay. Reject expired pending transactions, invalidate them after successful use, and return generic messages such as “The code could not be verified” rather than revealing whether an account or factor exists.
Sessions, trusted devices, and step-up checks
A successful 2FA check should not create an unlimited period of trust. Session lifetime should match account sensitivity, and session cookies should use Secure, HttpOnly, and an appropriate SameSite setting. Regenerate session IDs at login and after privilege changes. In token-based systems, validate the issuer, audience, expiry, signature, and intended scope rather than treating a decoded token as proof of identity.
“Remember this device” may reduce friction, but it is still a security decision. Treat it as a separate, revocable device token stored securely, with an expiration date, device-management controls, and a clear audit record. A browser name or user-agent string is not a trusted device identity. Require fresh authentication for sensitive operations, including changing an email address, generating recovery codes, adding a factor, exporting data, or changing billing permissions.
Recovery is part of the security boundary
Users lose phones and security keys. If recovery is improvised through support tickets or weak identity questions, it can become the easiest way around 2FA. Document the recovery process before enabling 2FA for real accounts.
- Generate several single-use recovery codes during enrollment.
- Show each code once and encourage offline storage in a password manager or secure physical location.
- Store only salted hashes of recovery codes, as you would for passwords.
- Allow users to register more than one strong factor when possible.
- Notify users through existing verified channels when factors, recovery options, or trusted devices change.
- Apply delays, risk review, and audit logging to high-impact recovery actions.
A reset link sent by email may be appropriate only when email ownership is an accepted recovery authority for the product. For administrator or financial accounts, use stronger procedures and do not allow a newly changed email address to immediately reset 2FA protections.
Operational controls that make 2FA dependable
Monitor authentication events without collecting secret values. Useful fields include the user ID, factor type, outcome, timestamp, coarse network and device signals, challenge or transaction ID, and the reason for a recovery or factor change. Watch for repeated failed attempts, a new factor followed immediately by recovery-code generation, or rapid changes to account contact details.
Test the full lifecycle in a staging environment: initial enrollment, failed code entry, clock drift, lost-device recovery, factor removal, multiple authenticators, logout, session expiry, and account deletion. Include accessibility testing. QR-only enrollment excludes some users, while recovery codes should be easy to copy, download, or print without appearing in logs or browser history.
For a practical rollout, start with staff and administrative accounts by enabling passkeys or TOTP. Require confirmation before activation, issue hashed single-use recovery codes, and confirm that a completed 2FA check rotates the session ID. This small end-to-end test can expose implementation mistakes before the feature is released to every user.
