← Back to Explainer Explainer

How WebAuthn and Passkeys Actually Work: The Cryptography That Makes Phishing Obsolete

Passkeys are a public key credential tied to a single account, plus a challenge signature that only a matched private key can produce and a specific origin can accept. Here is the cryptography and the FIDO2 trust chain behind the magic login button, and where the model still has real limits.

Passwords carry decades of accumulated problems. Every one of them is either stored in a database that can be stolen, reused across sites so one breach leaks many, or guessed and intercepted along the way. Phishing works because it asks for the same thing every time: what the password is. If you can drop passwords and ask for a signature that only works for a specific site and a specific moment instead, the whole attack surface changes. That is exactly what WebAuthn, the standard behind modern passkeys, was designed to do.

A passkey is simply a public key credential you own, created for one specific site or account. When your phone mints one, it stores the private key locally and shares the public key with the server, optionally wrapped in attestation that says which device made it. Because each passkey is scoped to a single account on a single origin, there is no universal password to leak. If one site is breached, it learns a public key that proves nothing on its own, which cannot log you in without the matching private key that lives on your device. That scoping is what makes passkeys different from a master password that quietly rides along behind every login.

Public keys, kept private

The foundation is a cryptographic idea that has been around for decades: asymmetric, or public key, cryptography. An authenticator such as your phone, a laptop with a fingerprint reader, or a dedicated hardware key generates a pair of keys. The private key stays inside the authenticator and is never sent anywhere. The matching public key is small, and it is fine to hand it to anyone, including the website you are signing into. A signature made with the private key can be verified against the public key, but the public key reveals nothing useful about the private key. You can think of the public key as a lock and the private key as the only copy of the key that turns it.

How a passkey login actually runs

A passkey login is a challenge and response. When you tap a passkey button on a site, the server generates a fresh random value called a challenge and sends it back. The server also identifies itself, essentially by the exact domain you are visiting. Your authenticator signs that challenge with its private key and returns the signature, plus the public key. The server verifies that the signature matches the public key and that the challenge is one it just issued. Because the challenge is random and short lived, a replayed signature from another session is useless, and because it is bound to a specific server, the signature will not verify on a different site.

  • The server sends a fresh one time random challenge and identifies the domain it represents.
  • The authenticator signs the challenge with a local private key that never leaves the device.
  • The signature and the matching public key are returned and verified on the server.
  • The result is bound to that specific origin and that specific moment, so it cannot be replayed or moved.

Attestation and the FIDO2 trust chain

Public key pairs by themselves do not stop a determined attacker from minting fake ones at will. So WebAuthn adds a second kind of trust: attestation. When you first register a new passkey, the authenticator can attach evidence about which device created the key, often a certificate from the device maker or a hardware module. Servers can weigh that evidence to distinguish a real, tamper resistant device from a software fake. Behind it all sits the FIDO2 trust chain: FIDO is the standards body that defines WebAuthn and the companion protocol CTAP that drives the physical or virtual authenticator. Registration and authentication each have well defined formats, and the trust anchors tie a device's proof of origin back to a chain of signed certificates that lets a server assess how much to trust the result.

Why phishing stops working

This is the part that makes phishing collapse. A phishing page runs on a different domain, so a signature it captures is bound to the phisher's origin, not the real one, and it will not be accepted. A stolen password is still useful, but a captured signature is useless outside its exact site and its exact time window. The private key never travels over the network at all, so there is no secret to intercept. Most passkeys are also tied to a specific account, which means there is no single reusable secret to leak from a data breach. You are no longer proving what a password is; you are proving that a particular device, bound to a particular site, signed for you right now. None of that can be faked by sending you to a lookalike page.

What this means for you

The practical picture

If you can turn passkeys on, do it for your email and anything sensitive. A passkey for your email account is the single lever that turns a whole cascade of account takeovers into a non event, because the login that unlocks the rest can no longer be phished. Pair one passkey with a recovery path and you have a strong, defensible default that costs nothing to switch to.

Nothing cryptographic is magic, and passkeys have limits. The authenticator still has to be protected from a thief with your phone or hardware key in hand, which is why biometric or PIN prompts sit in front of the signature. Cross device recovery, when your primary device is lost or broken, is the part of the ecosystem still maturing, and it is where most of the remaining design work lives. Adoption is now broad. Major browsers ship passkey support, major platforms from phone makers to cloud providers issue their own passkeys, and an increasing number of large services offer them at login. The security payoff is real: phishing is not gone, but for the largest accounts the most common and profitable version of it no longer works.

Sources: MiniOrange — What is WebAuthn and How Does it Work? (2026-10-05); Descope — WebAuthn: How it Works & Example Flows; Dashlane — What Is a Passkey and How Do Passkeys Work?.

Corrections: Report an error at corrections@wireshaman.com.

More from the wire