Passkeys Explained Simply

#webdev #discuss #security #api

You’ve probably seen that little prompt that says “Sign in with Face ID” or “Use a passkey” instead of the traditional password field. That’s a passkey. And no, it’s not just a password hidden behind your fingerprint.

The best password is the one you never have to type.

The Problem with Passwords

A password is a secret that you have to remember, and that the website has to store (ideally hashed). The problem is that this system relies entirely on two weak points:

You, who reuse the same password everywhere because you’re tired of coming up with a new one.
The website, which can be hacked and have its password database leaked.

Add phishing to that: a fake website that perfectly mimics the real one can steal your password without you even realizing it. And this isn’t just a minor issue: as the Verizon DBIR report reminds us every year, social engineering, phishing, and stolen credentials remain among the leading causes of hacking worldwide, alongside software vulnerabilities.

Source: Data Breach Investigations Report, Verizon

Even with a password manager and 2FA, the fundamental vulnerability remains: a secret that you could accidentally share.

What exactly is a passkey?

A passkey is based on asymmetric cryptography, the same principle as SSH, if you've ever generated a key pair to connect to a server.

When you create a passkey for a website:

Your device (phone, computer, security token) generates a key pair: a private key and a public key.
The private key never leaves your device. It is stored in a secure chip: the Secure Enclave on iPhone/Mac, the TPM on Windows, or directly on the chip of a USB key such as a YubiKey.
The public key, on the other hand, is sent to the website and stored on the server.

To log in, the site sends you a challenge (a random number), your device signs it with the private key, and the site verifies the signature using the public key. If they match, you're authenticated.

No secrets ever travel over the network only a signature. It’s written in black and white in the W3C WebAuthn spec: nothing to steal, nothing to phish.

Why It’s More Secure

Password	Passkey
Shared secret, transmitted with every login	Nothing is transmitted, just a signature
Reusable across multiple sites	Unique per site, tied to the domain
Vulnerable to phishing	Resistant to phishing (tied to the exact domain)
Can be leaked in the event of a server breach	The server stores only the public key, which is useless to an attacker
Must be memorized or managed via a manager	Unlocked via biometrics or a local code

The key point: a passkey is linked to the domain on which it was created. If you go to paypa1.com instead of paypal.com, your device won't even offer the passkey. It's the browser/OS that performs this verification, not you. Google explains it very well: unlike a password, a passkey is cryptographically bound to the site for which it was created, so it’s impossible to intercept or reuse on a fake site. They’re resistant to phishing by design, not because of the user’s good faith.

Under the Hood: WebAuthn and FIDO2

Technically, passkeys are based on the WebAuthn (W3C) standard, which is part of the broader FIDO2 standard promoted by the FIDO Alliance (whose members include Google, Apple, Microsoft, and Yubico). It is this API that browsers expose via JavaScript to create and use credentials.

Diagram of the registration flow, based on the W3C WebAuthn spec

Creating a client-side passkey looks like this:

const credential = await navigator.credentials.create({
  publicKey: {
    challenge: new Uint8Array(32), // provided by the server
    rp: { name: "My Super Site", id: "mysupersite.com" },
    user: {
      id: new Uint8Array(16),
      name: "thomas@example.com",
      displayName: "Thomas",
    },
    pubKeyCredParams: [{ alg: -7, type: "public-key" }], // ES256
    authenticatorSelection: { userVerification: "required" },
  },
});

And to log in with an existing passkey:

const assertion = await navigator.credentials.get({
  publicKey: {
    challenge: new Uint8Array(32), // provided by the server
    userVerification: "required",
  },
});

The server generates the challenge, the browser handles all the biometrics and unlocking, and sends you back a signature to verify. On the server side, libraries like @simplewebauthn/server in Node.js do most of the verification work.

What if I lose my phone?

This is the question that stumps everyone, and if this topic resonates with you, I’ve already written an entire article on the hassles of 2FA after a phone theft, the same “single point of failure” principle applies to passkeys. Since 2022, Apple, Google, and Microsoft have added passkey synchronization:

On iOS/macOS, they sync via your iCloud Keychain.
On Android/Chrome, they sync via your Google Account, using Google Password Manager, which encrypts everything end-to-end.
On Windows, via Windows Hello, although cross-device synchronization is even more limited there than with Apple or Google.

So if you lose your phone but regain access to your iCloud or Google account on a new device, your passkeys will be restored as well. You can also use a physical security key (YubiKey) as a backup, which doesn’t sync but works on any compatible device exactly the same advice as for traditional 2FA: never put all your eggs in one basket.

How to Use Them Today

More and more services already offer them: Google, Apple, GitHub, Microsoft, PayPal, Amazon, X... Google has even gone a step further by making passkeys the default for personal accounts. You’ll usually find them in your account’s security settings, under “Access Key” or “Passkey.”

The typical workflow:

Go to the service's security settings.
Click “Add an access key” or “Create a passkey.”
Your browser or operating system will ask you to confirm using Face ID, Touch ID, Windows Hello, or your phone's passcode.
That's it. The next time you log in, you won't need a password.

If you want to manage your passkeys somewhere other than your OS’s keychain (useful if you’re on multiple different platforms), ProtonPass can also create and store them—end-to-end encrypted—in the same place as your passwords.

Conclusion

| Question | Answer |
|--------------------------------------- -|-----------------------------------------------------|
| What is it based on? | Asymmetric cryptography (private/public key pair) |
| Does the password travel over the network? | No, never |
| Resistant to phishing? | Yes, by design (domain-bound) |
| Technical standard | WebAuthn / FIDO2 |
| Device loss | Recoverable via iCloud/Google sync, or physical backup key |

Passkeys aren't just “a password hidden behind a fingerprint”, they represent a complete shift in the model: nothing to remember, nothing to steal. If a service offers you the option to create one, go for it it's significantly more secure and faster than your current password.

The ProtonPass link in this article is an affiliate link, which means I may receive a commission if you decide to sign up through this link, at no additional cost to you. This helps me cover hosting and domain name fees. Thank you for your support!