Why can a passkey not be phished like a password?

A password is useful to anyone who learns it. A passkey login produces a signature over a fresh challenge, and that signature is bound to the requesting site’s origin. A fake site cannot obtain a signature that verifies for the real site, and it never receives a reusable secret to replay later.

What does my server store for a passkey?

Your server stores public verification material and metadata, not a secret. Typically that means a credential identifier, the public key, sign counter or related authenticator data, device or platform information if you collect it, and timestamps. The private key remains outside your database, on the user’s authenticator or passkey sync system.

Are passkeys just password-manager entries?

No. A password manager stores and fills a shared secret. A passkey is a cryptographic credential that proves possession of a private key without revealing it. The user experience may look like autofill or biometric approval, but the security mechanism is a signed, site-bound challenge rather than text being submitted.

Do passkeys remove the need for account recovery?

No. They reduce phishing risk during normal sign-in, but users still lose devices, change platforms, or need access from new environments. Recovery is where many systems weaken their security. If recovery falls back to email links, support overrides, or OTPs, those paths must be designed and monitored as part of the authentication system.

Passkeys & Phishing-Resistant Auth

Passkeys are phishing-resistant login credentials based on public-key cryptography, usually implemented with WebAuthn. Instead of sharing a password or code with a server, the user’s device proves possession of a private key by signing a fresh, site-bound challenge, while the application stores only public verification data and credential metadata.

Passwords fail because they are shared secrets: the user presents the same secret, or something derived from it, to whichever site asks. A convincing fake login page can collect that secret and reuse it. OTPs reduce the reuse window but do not remove the pattern: a code typed into a phishing site can be relayed to the real site quickly enough to work.

A passkey changes the login proof. When a user registers, their authenticator creates a key pair for your application. The private key remains with the device or its passkey sync provider. Your server stores the public key and a credential identifier. At sign-in, the server sends a fresh challenge, the authenticator signs it, and the server verifies the signature against the stored public key.

The phishing resistance comes from origin binding and non-exportable proof. A fake domain can ask the authenticator for a signature, but that signature is for the fake origin, not yours, so it will not verify for your login flow. Commonly misunderstood: a passkey is not a long password in a manager. The user cannot read it, paste it, or accidentally type it into the wrong page.

The trade-off is product and recovery complexity. Users may have several devices, synced passkeys, lost authenticators, or enterprise policy constraints. Your application also needs registration, authentication, credential management, and account recovery flows that do not quietly reintroduce phishable fallbacks. Whether passkeys replace passwords entirely or sit beside them depends on your users, platforms, support model, and risk tolerance.

In practice, engineers meet passkeys through WebAuthn APIs, browser and operating-system prompts, and database schema changes. A user should be able to have multiple credentials. Each credential record stores a credential id, public key, sign counter or related metadata, device hints, and timestamps. Your database should never contain the private signing key or a password-equivalent value that can be replayed.

Go deeper

User SystemsPasskeys & Phishing-Resistant AuthExplain why a passkey cannot be phished the way a password or an OTP can, and what changes in your data model when you store one.Open the lesson

Common questions

Why can a passkey not be phished like a password?: A password is useful to anyone who learns it. A passkey login produces a signature over a fresh challenge, and that signature is bound to the requesting site’s origin. A fake site cannot obtain a signature that verifies for the real site, and it never receives a reusable secret to replay later.
What does my server store for a passkey?: Your server stores public verification material and metadata, not a secret. Typically that means a credential identifier, the public key, sign counter or related authenticator data, device or platform information if you collect it, and timestamps. The private key remains outside your database, on the user’s authenticator or passkey sync system.
Are passkeys just password-manager entries?: No. A password manager stores and fills a shared secret. A passkey is a cryptographic credential that proves possession of a private key without revealing it. The user experience may look like autofill or biometric approval, but the security mechanism is a signed, site-bound challenge rather than text being submitted.
Do passkeys remove the need for account recovery?: No. They reduce phishing risk during normal sign-in, but users still lose devices, change platforms, or need access from new environments. Recovery is where many systems weaken their security. If recovery falls back to email links, support overrides, or OTPs, those paths must be designed and monitored as part of the authentication system.

Every term