Passkeys vs passwords, SMS codes and magic links
Passkeys vs passwords, SMS one-time codes and email magic links: how each works, what attacks it stops, what it costs to run, and where each still belongs.
Passkeys beat passwords, SMS codes and magic links on security because they are the only one of the four where nothing reusable or phishable is ever typed, sent or stored on the server. A password can be guessed, reused, phished or leaked from a database. An SMS code can be phished in real time or intercepted through SIM swapping. A magic link inherits the security of the user’s inbox. A passkey is a private key that never leaves the user’s device and only signs for the exact website it was created on, so a fake site gets nothing it can use.
Each method still has a place, though. Here’s how they compare and where each one belongs.
The short comparison
| Password | SMS code | Magic link | Passkey | |
|---|---|---|---|---|
| What the user does | Types a secret | Types a code from a text | Clicks a link in email | Unlocks their device |
| Secret on your server | Password hash | Short-lived code | Link token | Public key only |
| Phishable | Yes | Yes, in real time | Yes, if the inbox is compromised or the link is forwarded | No, bound to your domain |
| Reusable across sites | Often (password reuse) | No | No | No |
| Breach impact | Hashes can be cracked | Low | Low | None for sign-in |
| Per-sign-in cost | None | SMS delivery fee | Email delivery | None |
| Speed for the user | Slow without a manager | Slow, depends on delivery | Slow, leave the app to check email | Fast, one biometric prompt |
Passwords
Passwords are a shared secret: the user knows it and the server stores a hash of it. Their problems are well understood:
- Reuse. Users repeat passwords across sites, so a breach somewhere else becomes credential stuffing against you.
- Phishing. A convincing fake login page collects the password directly.
- Storage risk. Even properly salted, slow hashes can be cracked when the password is weak.
- Operational cost. Reset flows, complexity rules, breached-password checks and lockout policies all need building and support.
Password managers fix reuse and some phishing, but only for users who use them consistently.
SMS one-time codes
SMS codes are usually a second factor, sometimes the only factor. They add real protection against password reuse, but they have three weaknesses:
- Real-time phishing. A phishing proxy asks the user for the code and forwards it to the real site within seconds. The code is valid, so the attacker gets in.
- SIM swapping and number recycling. If an attacker convinces a carrier to move the victim’s number, or a number is reassigned, the codes go to someone else.
- Cost and deliverability. Every code is a paid message, delivery varies by country and carrier, and SMS pumping fraud can run up bills.
Authenticator-app codes (TOTP) avoid the carrier problems but are just as phishable in real time. We explain why in why passkeys stop phishing.
Email magic links
A magic link emails the user a one-time URL that signs them in. It removes passwords entirely, and users understand it. But:
- Security equals the inbox. Anyone who can read the user’s email can sign in.
- Friction. Users leave your app, wait for delivery, search spam, and often open the link on a different device than the one they started on.
- Link handling. Email security scanners sometimes prefetch links, which can consume single-use tokens unless the flow requires a confirming action.
Magic links are a good fit for proving someone controls an email address. They’re a weaker fit for signing in every day.
Passkeys
A passkey is a WebAuthn credential: a key pair where the private key stays with the user’s authenticator and your server keeps the public key. To sign in, the device signs a challenge from your server after the user unlocks it. Our developer’s guide to passkeys covers the ceremony in detail.
What that buys you:
- No shared secret. Your database stores public keys, which are useless to an attacker.
- No reuse. Each passkey is unique to one site.
- Phishing resistance. The browser only offers a passkey to the domain it was created for.
- Speed. One Face ID, Touch ID or Windows Hello prompt, and synced passkeys follow users to new devices through iCloud Keychain, Google Password Manager or 1Password.
The honest trade-offs:
- Recovery needs a plan. If a user loses every device with a passkey and doesn’t use a synced provider, you need a way back in. See passkey account recovery.
- Shared and older devices. Some environments, such as locked-down kiosks, may not support platform authenticators. Users can usually sign in with a phone via the QR-code cross-device flow or a hardware security key.
Where each method belongs
You don’t have to pick one method for everything. A sensible split:
| Job | Best fit |
|---|---|
| Everyday sign-in | Passkey |
| Verify an email address at signup | Magic link |
| Recover an account after losing every device | Magic link, with old credentials revoked |
| Second factor on a password account you can’t migrate yet | Authenticator app or security key, not SMS |
| Anything new | Don’t add passwords |
The important rule: a strong method is only as strong as the weakest one that can also sign in. If a user can still sign in with a password or an SMS code, an attacker will skip the passkey and use that. Passkey-first means passkey-only for everyday sign-in.
Migrating an existing app
If you already have password users, migrating usually looks like:
- Offer passkey enrollment right after a successful password sign-in.
- Make passkey the default sign-in method once enrolled.
- Stop accepting passwords for accounts that have a passkey.
- Set a date for new accounts to be passkey-only.
The fastest route for a new app is to skip step one entirely and launch without passwords.
How Gatekeep splits the jobs
Gatekeep uses exactly the split in the table above. Everyday sign-in is passkey-only, with no passwords and no SMS codes. Email magic links are used only to verify an address at signup and to recover an account, never for routine login. Links expire after 10 minutes and work once, and completing recovery revokes every existing passkey on the account.
See creating an account, signing in and the security model, then request early access.