Information Security · Authentication

TOTP made the code stay home. Passkeys make the secret never exist.

TOTP solved the delivery problem — codes are computed on the device instead of sent. But there is still a code, still a shared secret on the server, and still a human being asked to type the right thing into the right place. WebAuthn and passkeys remove all three.

The Core Idea

No shared secret. No code to type. No way to use it on the wrong site.

Asymmetric Crypto

The server keeps your public key. The matching private key never leaves your device.

Origin-Bound

The credential is cryptographically tied to the real domain. A fake site cannot use it.

Device Verifies You

A biometric or PIN unlocks the signing operation. Locally, on hardware you own.

Standard, Everywhere

W3C WebAuthn and FIDO2 — built into every modern browser and operating system.

The Gap In TOTP

A computed code is still a code — and a code can still be phished.

TOTP is a huge improvement over SMS and email OTP because it stops the secret being transmitted to you. But the model still depends on a shared secret on the server, a code on a screen, and a human in the middle deciding which website to type it into.

The secret is still shared

TOTP is symmetric crypto. The server stores the same secret your device stores. A server breach exposes every user's TOTP secret in one go.

The code is still phishable

A convincing fake login page can ask for the TOTP code — the user types it in, and an attacker relays it to the real site within the 30-second window. The user is the only one verifying the URL.

Real-time MITM proxies

Tools like Evilginx automate this attack. The fake site captures the username, password and TOTP code, replays them through to the real site in real time, and steals the resulting session cookie.

The user is the verifier

TOTP works only as well as the user's ability to inspect a URL. Lookalike domains, punycode tricks and homoglyphs defeat that check routinely. Humans are not reliable origin validators.

Enrolment is fragile

The QR code shown at setup is the secret, in plain sight. A screenshot, a screen share or a shoulder over a desk — and the second factor is no longer a second factor.

Lost device, lost access

Most TOTP apps do not sync. When a phone is lost, every account it protected falls back to the recovery flow — and recovery flows are typically the weakest link in the chain.

The Exchange

Two ways to complete a logon.

The TOTP exchange asks a human to ferry a code from one screen to another. The passkey exchange asks a device to sign a challenge for a specific website. Only one of these is a job humans are good at.

Side By Side

Shared secret vs. signed challenge.

Property TOTP — Shared Secret Passkey — WebAuthn
Cryptography Symmetric — same secret on both sides Asymmetric — public key on server, private key on device
Where the secret lives On the server and on your device Only on your device — server has no usable secret
Server breach impact Severe — every TOTP secret exposed Negligible — public keys are not credentials
Phishing resistance No — code can be typed anywhere Yes — credential bound to origin by the browser
Real-time MITM proxies Vulnerable — codes can be relayed Defeats them — signature won't validate for the wrong origin
What the user does Read 6 digits, type 6 digits Touch a sensor or look at a camera
Replay attacks Limited window — valid for ~30 seconds Impossible — each challenge is fresh and single-use
Cross-device sync App-by-app, mostly manual Built in — iCloud Keychain, Google Password Manager, 1Password
Standard RFC 6238 W3C WebAuthn · FIDO2 / CTAP2

Passkeys are the user-facing name for synced WebAuthn credentials — the underlying cryptography is the W3C WebAuthn standard, paired with the FIDO2 / CTAP2 protocol between the browser and the authenticator (an OS, a phone or a hardware key).

The Mechanism

How a passkey signs you in without a secret to share.

WebAuthn is a small piece of asymmetric cryptography wired into the browser. There is no code on a screen, no secret on a server — only a challenge and a signature.

STEP 01

Server sends a challenge

You ask to log in. The server generates a random challenge and sends it to the browser, along with the origin — the exact domain the request is for. Stored alongside: your public key from when you registered.

STEP 02

Device signs locally

The browser finds the credential bound to that origin. It asks you to confirm with a biometric or PIN. The device signs the challenge with your private key. The private key never leaves the secure element on your device.

STEP 03

Server verifies the signature

The browser returns the signature. The server checks it against your stored public key using verify(publicKey, challenge, signature). Valid — you are signed in. Wrong origin or wrong key — refused.

The key insight: the browser will only use a credential on the origin it was registered for. A convincing copy of your bank's login page at attacker-bank.com cannot make the credential sign anything — the browser refuses to surface it. There is nothing to phish, because there is nothing for the user to type.

The entityOS Position

Move the verifier from the user to the machine.

entityOS treats authentication as a cryptographic exchange between known endpoints, not a code passed through a person. Passkeys are the public-web expression of that principle. Inside closed systems, the same idea takes the form of client certificates and self-sovereign credentials.

01

Prefer asymmetric over symmetric

Public keys cannot be turned into credentials. A breach of the server gives the attacker the front door — not a copy of every key.

02

Let the browser do the origin check

WebAuthn binds the credential to the registered domain. The job humans have always failed at — spotting a fake URL — is now done by the browser, deterministically.

03

Use the device as the secure element

Modern phones and laptops ship with hardware-backed key storage. The private key lives in the secure enclave; biometrics gate its use. The credential is built into the device, not stored on it.

04

For closed networks, the same idea is mTLS

Mutual TLS with X.509 client certificates is WebAuthn's enterprise cousin: asymmetric crypto, server holds public material, identity is verified by signature — not by code. entityOS uses mTLS to extend the model into closed infrastructure.

05

And for the long term, KERI / ACDC

Self-sovereign identity removes the central trust anchor entirely. The entity holds and presents its own verifiable credential — no shared secret, no platform custodian, no recovery flow to phish.

What passkeys still ask of you

Passkeys are the strongest consumer authentication available today — but they are not the end of the security story. The credential typically syncs through a platform provider (Apple, Google, Microsoft) or a password manager, which means trust shifts to that custodian. Account recovery flows can still be social-engineered. And in closed organisational systems, you may want the trust anchor inside your own perimeter — which is where mTLS with organisationally-issued certificates earns its place. The principle holds throughout: the fewer parties hold the secret, and the more the verification is done by code rather than by humans, the stronger the system.

In Summary

Three things to take away.

TOTP fixed delivery. Passkeys fixed the model.

TOTP stopped the secret being transmitted. Passkeys stop there being a shared secret at all.

The browser is the verifier

Origin checking is done by code, not by a tired human reading a URL. That single change defeats whole classes of phishing.

The same principle scales further

mTLS for closed networks, KERI / ACDC for self-sovereign identity — same idea, stronger custody. Asymmetric crypto, all the way down.

The safest secret is the one that never travels. The safer one is the one that never exists. Passkeys take that step — the credential is generated on your device, stays on your device, and proves you by signing, not by sharing.