bauth - Expert Advice for Better Authentication

Passwords alone are no longer a defensible security posture for anything handling sensitive data, and most developers know it. The harder question is which additional factor to add, and how to implement it without turning login into a friction-heavy chore that drives users away. TOTP and passkeys solve overlapping but distinct problems, and the implementation details of each determine whether they actually improve security or just add an extra step attackers route around.

Want expert help putting this into practice? B-Auth Pro can guide you through it.

TOTP: Simple, Proven, and Still Phishable

Time-based one-time passwords work by having the server and an authenticator app (Google Authenticator, Authy, 1Password, and similar) share a secret at enrollment, then independently generate a six-digit code from that secret and the current time, refreshed every 30 seconds. The appeal is real: it's a well-understood standard (RFC 6238), works offline, and doesn't require specialized hardware. The weakness is equally real — TOTP codes are phishable. A convincing fake login page can prompt a user for their code and relay it to the real site in real time, completing the login as the attacker. TOTP is a meaningful improvement over passwords alone, but it isn't phishing-resistant, and treating it as equivalent to passkeys overstates its protection.

Passkeys: Phishing-Resistant by Construction

Related: bauth Best Practices for Secure and Efficient Authentication.

Passkeys, built on the WebAuthn/FIDO2 standard, take a fundamentally different approach. Instead of a shared secret that a user can be tricked into typing anywhere, authentication uses public-key cryptography: the private key never leaves the user's device or hardware authenticator, and the browser cryptographically binds the authentication ceremony to the specific origin requesting it. A fake login page simply cannot complete a passkey challenge for the real site — there's no code to steal because there's no code involved. This is the property that makes passkeys categorically more phishing-resistant than TOTP, not just incrementally better. The tradeoff is integration complexity and platform variability — passkey UX still differs across browsers, operating systems, and whether a user is syncing credentials via a platform authenticator or using a dedicated security key.

Enrollment Design Determines Real-World Adoption

The best MFA method is the one users actually complete enrollment for. A TOTP enrollment flow that requires scanning a QR code, then manually entering a confirmation code, loses users at every step if the instructions aren't crystal clear. Passkey enrollment benefits from platform-native prompts (Face ID, Windows Hello, a hardware key tap) that feel closer to a native app flow than a security form. Whichever factor you offer, always display a fallback method and recovery codes at enrollment time — not buried in account settings — since the moment a user loses access to their second factor is the moment they most need to find that information quickly.

Step-Up Authentication: MFA Isn't Just a Login-Time Check

See also: bauth Best Practices: Secure and Efficient Authentication.

A common design mistake is treating MFA as a single gate at login, after which the session is fully trusted for its entire lifetime. Sensitive actions deserve a fresh authentication challenge regardless of how recently the user logged in — changing an email address, adding a new payment method, generating an API key, or exporting account data. This pattern, often called step-up authentication, means a stolen session cookie or token doesn't automatically grant an attacker the ability to perform the account's most consequential actions. Implementing it requires tracking when the last MFA challenge occurred, not just whether one ever occurred.

Recovery Codes and Backup Methods Need Their Own Threat Model

Every MFA system needs a way to handle lost devices, and that recovery path is frequently where security quietly degrades. Recovery codes should be generated in a batch at enrollment, displayed exactly once, hashed before storage (never kept in plaintext, the same way you'd never store a password in plaintext), and invalidated individually as each is used. Support-driven account recovery — a human resetting MFA after a phone call — is a well-known social engineering target; if you offer it, it needs identity verification at least as rigorous as the MFA it's bypassing, not a name and a billing zip code.

Rolling Out MFA Without Losing Users

Mandating MFA for every user on day one is rarely realistic, especially for consumer products where friction directly affects conversion. A staged approach works better in practice: make MFA available and lightly encouraged for all users, require it for accounts with elevated privileges or access to sensitive data, and consider risk-based prompts that request a second factor only when a login looks anomalous (new device, new location, impossible travel). This gets most of the security benefit without forcing every casual user through an enrollment flow they may abandon.

Don't Ignore SMS as a Fallback, but Don't Lead With It Either

SMS-delivered one-time codes are still common as a fallback method, largely because every user has a phone number and no app installation is required. The tradeoff is real: SMS is vulnerable to SIM-swapping attacks, where an attacker social-engineers a mobile carrier into porting a victim's number to a new device, then intercepts the code directly. It's also dependent on carrier infrastructure that can introduce delivery delays, which shows up as support tickets during time-sensitive login attempts. The pragmatic position most security-conscious teams land on: offer SMS as a fallback option for users who can't or won't use an authenticator app or passkey, but don't present it as equivalent in strength to TOTP or WebAuthn-based methods, and avoid making it the only available second factor for any account handling genuinely sensitive data.

Implementing This Correctly Without Reinventing WebAuthn

TOTP is relatively easy to implement directly; WebAuthn/passkeys are not — the specification is detailed, browser behavior varies, and getting attestation and credential management wrong has real security implications. This is exactly the kind of infrastructure worth sourcing rather than building, which is where a provider like B-Auth Pro fits: TOTP, passkeys, step-up authentication, and secure recovery-code handling implemented once, correctly, rather than re-derived by every team that decides passwords alone aren't enough.

Better authentication isn't about picking a single "best" factor — it's about understanding what each one actually protects against, TOTP's real but limited improvement over passwords, and passkeys' structural resistance to phishing, then designing enrollment, step-up checks, and recovery flows that hold up under real-world usage rather than just passing a security checklist.