
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.
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:
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.
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:
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.
| 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.
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.
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:
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.
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:
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.
| 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!