Passkeys vs passwords vs OTP
Published
Every login proves one of three things. Something you know: a password, a PIN. Something you have: a phone that receives an OTP, a security key. Something you are: a fingerprint, a face. Multi factor authentication means proving two different kinds, which is why a password plus a security question is still one factor: both are things you know.
Passwords, OTPs and passkeys sit at three points on a scale of how easy they are to steal. The interesting part is how each one gets stolen, because that tells you what the next one fixes.
A phishing site that looks exactly like your bank asks for your password, then for the OTP the bank just sent you. You type both. Did the OTP protect you? What would have?
Passwords: something you know, and so does the attacker#
A password is a shared secret: you know it, and the server knows enough to check it (a slow salted hash, see hashing vs encryption). Its failures are well known and they are mostly human:
- Reuse. One site leaks, and attackers try the same email and password everywhere. This is credential stuffing, and it is the most common account takeover on the internet.
- Phishing. You type it into the wrong site.
- Guessing.
Password@123satisfies most complexity rules and is in every attack list.
Current advice (NIST SP 800-63B) is to allow long passphrases, check new passwords against
known breached lists, and stop forcing periodic changes and symbol rules, which only produced
Password@124.
OTP: something you have, delivered as a number#
A one time password adds a second factor. There are two kinds that matter:
- SMS OTP: the server texts you a six digit code. Familiar, especially in India, where it confirms everything from card payments to DigiLocker logins. Weak against SIM swap (an attacker convinces the operator to move your number to their SIM) and against interception of the phone network.
- TOTP: an authenticator app (Google Authenticator, Authy, Microsoft Authenticator) computes the code locally from a secret shared once via QR code, plus the current time in 30 second steps (RFC 6238). No SMS involved, so no SIM swap.
Both fail the same way against modern phishing. A reverse proxy phishing kit (Evilginx is the well known open source one) sits between you and the real bank, passing everything through in real time. You type the password, it forwards it; the bank sends an OTP; you type it into the fake page; it forwards that too, within seconds, and keeps the session cookie the bank returns. The code was valid. It was just used by the wrong person.
Passkeys: something you have, that cannot be typed into the wrong site#
A passkey is a key pair, built on the WebAuthn and FIDO2 standards. When you register, your device creates a new private key for that website only, keeps it in secure hardware, and sends the site the public key. To log in, the site sends a random challenge; your device asks for your fingerprint or face or PIN (that only unlocks the key, it never leaves the device), signs the challenge, and the site checks the signature with the stored public key.
That is the property to remember: passkeys are phishing resistant by construction, because the browser binds every signature to the real origin. They also defeat credential stuffing (every site has a different key) and server breaches (only public keys are stored).
Passkeys sync through your platform's password manager, iCloud Keychain, Google Password Manager or 1Password, so a new phone does not lock you out. Device bound passkeys on a hardware security key (a YubiKey) do not sync, which is what high security setups want. Google reported in 2023 that passkey sign ins succeed about four times as often as passwords, so they are faster for users, too.
| Choice | What you gain | What you pay | Pick it when |
|---|---|---|---|
| Password alone | Works everywhere, no device needed. | Reused, guessed, phished, stuffed. One factor. | Only as one factor among two, and only while you migrate. |
| Password + SMS OTP | Stops credential stuffing. Everyone already knows how to use it. | SIM swap, SMS costs (a few paise each, which adds up at scale), and real time phishing relays. | Mass market apps where reach matters more than phishing resistance. |
| Password + TOTP app | No SIM swap, works offline, free. | Still phishable in real time. Users lose phones and their seeds. | Developer tools, admin panels, as a step up from SMS. |
| Passkey | Phishing resistant, nothing reusable, nothing worth stealing on the server, quick. | Account recovery needs care. Shared and older devices are awkward. | The default for new consumer login. Mandatory for admins and staff. |
Your login is only as strong as your account recovery. If a forgotten passkey can be reset with an SMS OTP, the attacker just does the reset. Design recovery deliberately: a second registered passkey, recovery codes shown once, or identity verification for high value accounts. Then rate limit and alert on recovery attempts.
- FIDOFIDO Alliance, the standards body behind passkeys
- WeWebAuthnThe browser API: navigator.credentials.create() and .get()
- Google AuthenticatorTOTP codes from a shared secret and the clock
- GoogleGoogle Password Manager syncs passkeys on Android
- YuYubiKeyHardware security key, device bound passkeys
- EvEvilginxReverse proxy phishing kit that relays OTPs
In the interview#
Checkpoint#
1. A phishing proxy captures your password and the SMS OTP. Why did the OTP not help?
2. Why can a passkey not be phished?
3. What does the server store for a passkey?
- Three factors: know, have, are. MFA means two different kinds.
- Passwords fail to reuse and phishing. OTPs fail to real time phishing and SIM swap.
- Passkeys: a key pair per site, origin bound, phishing resistant, server stores a public key.
- TOTP: shared secret + time in 30 second steps.
- Account recovery is the weakest link. Design it, do not bolt it on.
Logins prove something you know, have or are, and multi factor means two different kinds. Passwords are shared secrets that get reused, guessed and phished, so credential stuffing is the most common takeover. One time passwords add something you have, but SMS is exposed to SIM swaps, and both SMS and authenticator codes can be relayed in real time by a phishing proxy. Passkeys, built on WebAuthn and FIDO2, create a key pair per site; the device signs a random challenge after a local biometric or PIN, and the browser binds the signature to the real origin, so a look alike site gets nothing usable. The server stores only a public key, so a breach leaks nothing reusable. I would offer passkeys by default, prompt users to add one after login, require them for staff, and design account recovery carefully because it is usually the weakest path.