The Problem with Passwordless Authentication

Sam Erickson
Updated 6 days ago
0

Key Takeaways

Passwordless authentication removes the application password, not the need to secure authentication, recovery, and sessions.
Correctly implemented WebAuthn passkeys provide phishing resistance; email links and SMS codes do not provide the same protection.
Synced passkeys improve availability across devices but add trust in the credential provider’s account, synchronization, and recovery controls.
Evaluate the complete account lifecycle: enrollment, everyday login, device loss, fallback, and credential replacement.

Passwordless authentication security depends on how you prove account control, not whether the login form has a password field. Passkeys remove reusable application passwords and resist phishing; email links and SMS codes instead rely on access to a delivery channel. Recovery and session handling remain security boundaries in either design.

The problem isn’t passwordless authentication itself. It’s treating materially different methods as equivalent—or assuming a convenient login experience makes the whole account secure.

What Passwordless Authentication Actually Means

For this article, passwordless means signing into an application without supplying an application password. That doesn’t necessarily mean the service has removed every password-based fallback, or that an upstream email or credential-provider account never uses a password.

Distinguish three deployment goals: passwordless everyday login, no application password stored, and an entirely passwordless account lifecycle. Ask which one a proposed implementation actually delivers.

The benefit is real, not merely a reshuffling of identical vulnerabilities. With passkeys, the application stores a public key rather than a reusable password secret, and credentials are scoped to the relying party—the application accepting authentication. Password reuse and credential stuffing therefore don’t work against the passkey itself.

From Email Links to WebAuthn Passkeys

Email links, one-time codes, and public-key credentials are different approaches, not successive versions of one protocol. WebAuthn became a W3C Recommendation on March 4, 2019, well before 2024. FIDO2 combines WebAuthn with the FIDO Alliance’s Client-to-Authenticator Protocol, or CTAP.

A passkey is a discoverable WebAuthn public-key credential: the authenticator can find it for the application without the application first supplying its credential ID. An authenticator is the device or software that holds and uses the credential.

The important comparison is what an attacker must control. NIST’s authenticator guidance explains why manually entered one-time codes are not phishing-resistant: an impostor can relay them to the real service.

Method	What proves access	Phishing resistance	Operational tradeoff
Email magic link	A valid token delivered to an inbox	Not inherent; link credentials can be exposed or relayed	Delivery, spam filtering, link handling, and inbox recovery
Email one-time code	A valid code delivered to an inbox	No; a code can be relayed	Manual entry and dependence on email availability
SMS one-time code	A valid code delivered to a phone number	No; a code can be relayed	Carrier delivery, message costs, and phone-number ownership
Synced passkey	A signed assertion from a registered credential	Yes, with correct ceremony verification	Credential-provider integration, synchronization, and recovery
Device-bound passkey on a security key	A signed assertion from that authenticator	Yes, with correct ceremony verification	Hardware procurement, compatible connections, and replacement planning

A security key can support passwordless passkeys when it supports discoverable FIDO2 credentials. Don’t assume a legacy second-factor-only key can replace the complete password login flow.

Passkey Security: Synced Versus Device-Bound

Synced passkeys and device-bound passkeys use different availability models. Synced credentials can become available on another device through the credential provider; device-bound credentials remain on one authenticator, which may be built into a device or carried as a security key.

Synchronization can simplify device migration and recovery, but expands the trust boundary to the provider’s device-enrollment, synchronization, and account-recovery controls. Device-bound credentials avoid that synchronization dependency but require another registered authenticator or a deliberate recovery process if the device is lost.

Neither model requires sending a fingerprint or face scan to your application. Biometric verification is local, and a PIN can be a non-biometric verification method.

Passwordless Is Not Automatically MFA

Multifactor authentication requires distinct factors: something you know, something you have, or something you are. Removing a password doesn’t establish that requirement.

A passkey used with local user verification can combine possession of the authenticator with a PIN or biometric. User presence—such as touching a security key—is not the same as user verification. If your policy requires verification, request userVerification: "required" and verify the returned UV flag on the server; don’t infer MFA merely from the presence of a passkey.

Where Passwordless Authentication Risks Move

Email and SMS Remain Vulnerable Channels

An attacker controlling an inbox may be able to access accounts that accept that inbox for authentication or recovery. That does not mean every account associated with the address is automatically compromised: additional checks and the account’s recovery policy still matter.

SIM swapping lets an attacker intercept SMS codes after taking control of the victim’s phone number. Number recycling creates a separate problem: a former user’s number can belong to someone else. Treat phone-number reassignment as a lifecycle risk, not just a delivery failure.

Codes can also be phished in real time. Push-based approval flows have their own fatigue risk: repeated prompts intended to make the user approve an attacker’s request.

A passkey-only login screen is misleading if an attacker can choose “lost device,” receive an email, and immediately enroll a replacement credential. The recovery route has become an alternative way into the account.

Primary path: registered passkey --> verified assertion --> session
Recovery path: recovery evidence --> replacement enrollment --> session

Review both paths against the account's required assurance.

OWASP’s passkey lifecycle guidance recommends multiple authenticators and recovery controls appropriate to the application’s risk. Let users register a backup before they lose the first device. Consider separately secured, single-use recovery codes and a reviewed support-assisted process where appropriate.

Require recent reauthentication before adding credentials or changing recovery methods. Notify users of changes, record recovery events, and revoke credentials and sessions identified as compromised. Don’t silently downgrade a phishing-resistant account to email or SMS after an ordinary login error.

The older claim that passwordless systems inevitably require passwords is wrong. An application can have no password at all; its remaining dependencies depend on the authenticators and recovery paths you choose.

Brute Force, Notification Bombing, and Delivery Abuse Differ

Guessing a short code is a brute-force attack. Repeatedly requesting messages is notification bombing or delivery abuse; it can exhaust budgets or make legitimate sign-in unavailable without guessing anything.

Apply authentication abuse controls separately to requesting credentials and redeeming them:

Code guessing: bound failed verification attempts by account and transaction. A resend must not reset account-level failure counts.
Account enumeration: use consistent public messages, status codes, and comparable response timing whether an account exists.
Notification bombing: combine recipient cooldowns with account, network, and device limits. A fresh transaction identifier must not bypass recipient limits.
Delivery-cost abuse: cap aggregate sending and restrict unsupported destinations. Monitor sending volume against successful verification, as described in Twilio’s SMS fraud guidance.

Don’t lock an account merely because someone requested login links. Otherwise, your protection becomes an account-lockout denial-of-service mechanism.

Sessions and Compromised Endpoints Still Matter

A stolen bearer session cookie can let an attacker use an already-authenticated session without repeating passkey authentication. Malware or malicious application scripts can also abuse an authenticated browser; phishing resistance is not endpoint-compromise resistance.

Follow secure session-management practices: rotate the session identifier after authentication, use Secure and HttpOnly cookies with an appropriate SameSite policy, enforce server-side expiration, and protect state-changing requests against CSRF. Use HTTPS throughout the session, not only on the login page; see how TLS works for the transport boundary.

Implementing Passwordless Authentication Securely

Verify the Complete WebAuthn Ceremony

WebAuthn binds authentication to the relying-party ID, or RP ID, and the calling origin. The RP ID scopes the credential to a domain; the origin identifies the web context that requested it. A lookalike site on an unrelated domain cannot simply request the legitimate site’s passkey.

Use a maintained server library implementing the WebAuthn verification procedures. This is a flow outline, not production code or an exhaustive verification checklist:

Server: create a fresh, unpredictable challenge
        bind it to the login transaction, policy, and expiration
   |
   v
Browser: navigator.credentials.get({ publicKey: options })
   |
   v
Authenticator: perform required local verification; sign assertion
   |
   v
Server: verify ceremony type, challenge, expected origin, RP ID hash,
        credential/account association, signature, presence, and
        required user verification; enforce extension/frame policy
   |
   v
Server: atomically consume the challenge; issue a fresh session

Reject expired or reused challenges. Resolve the authenticated account from verified credential records, not a client-supplied email address. Enforce the expected origins explicitly rather than accepting whatever origin arrives with the response.

Registration is a separate authorization boundary. navigator.credentials.create() starts credential creation; your server must verify registration before attaching the credential to the intended account. Bind enrollment to an authorized account-creation or reauthentication transaction, and validate the challenge, origin, RP ID, verification flags, allowed algorithm, and applicable attestation policy.

Treat Magic Links as Authentication Credentials

A sign-in link is not merely a password-reset shortcut. Its token authorizes authentication. Adapt the token-handling principles in OWASP’s recovery guidance, while keeping sign-in and password-reset purposes separate:

Generate an opaque token using a cryptographically secure random generator. Store only its hash, associated account, login purpose, expiry, and transaction context.
Build the link from a configured trusted HTTPS origin, not an untrusted request host. Allowlist post-login redirect destinations.
Keep tokens out of application, proxy, analytics, and tracing logs. Use Referrer-Policy: no-referrer on token-handling pages and avoid third-party resources there.
Where supported by the flow, bind redemption to the initiating browser transaction. Design cross-device use explicitly rather than accidentally dropping that protection.
At redemption, validate the token hash, account binding, purpose, expiration, unused state, and required transaction context. Consume it atomically so concurrent requests cannot both succeed.
Only after successful validation and consumption, issue a fresh authenticated session and redirect to an approved destination without the token.

A redirect alone proves nothing about identity.

Email security scanners may open links before users do, consuming credentials in flows that redeem on the first visit. Supabase documents this prefetching failure. Consider an intentional confirmation action rather than authentication on the first GET, protect that action against CSRF, and test actual scanner behavior. Choose short expirations that accommodate delivery delays and accessibility needs; there is no universal lifetime suitable for every application.

Choose for Your Application, Not the Label

For accounts where phishing resistance matters, prefer correctly verified passkeys over transferable email or SMS credentials. For higher-assurance enterprise use, evaluate managed device-bound authenticators, attestation requirements, and replacement operations. The FIDO enterprise deployment resources explain those policy choices.

Before rollout, test the complete experience across your supported browsers, operating systems, credential providers, and security-key connections. Include keyboard and screen-reader use, PIN-based and biometric paths, shared devices, device migration, and loss of every registered authenticator.

Budget for email/SMS delivery and abuse prevention versus passkey enrollment, recovery, and support engineering. Hardware keys add procurement and replacement work. Don’t assume passwordless means cost-free or universally easier.

If an identity provider handles sign-in, review its enrollment and recovery policies too; our OpenID Connect example explains the application integration. Delegating authentication doesn’t remove your responsibility to understand the resulting trust boundary.

The right question isn’t “Should we discard passwords?” It’s “Which attacks does this method prevent, which dependencies does it introduce, and can an attacker bypass it through recovery or session handling?”

FAQ

Are passkeys and passwordless authentication the same thing?

No. Passwordless authentication describes signing in without an application password; passkeys are one implementation using WebAuthn public-key credentials. Email magic links and SMS codes are also passwordless methods, but have different security properties.

Are passkeys more secure than email magic links or SMS codes?

Correctly implemented passkeys provide phishing resistance through credential scoping and origin verification, unlike transferable links and manually entered codes. Their overall account security still depends on enrollment, recovery, credential-provider controls, and session protection.

Can WebAuthn authentication be phished?

A correctly verified WebAuthn ceremony resists lookalike-site and credential-relay phishing through relying-party scoping and origin binding. Attackers may instead target weaker fallback methods, account recovery, authenticated sessions, or compromised endpoints.

What happens if I lose the device with my passkey?

A synced passkey may remain available through another device or the credential provider’s recovery process. A device-bound passkey requires another registered authenticator or an application recovery process if its authenticator is unavailable. Set up and test backup access before losing the device.

Is passwordless authentication automatically MFA?

No. A passkey with enforced local user verification can combine possession with a PIN or biometric, but passwordless login by itself does not establish multiple factors. The server must enforce the intended verification policy rather than assume that every passkey operation satisfies it.