The idea, explained
Begin with two related keys. The private key produces a digital signature: a mathematical proof tied to particular data. The public key checks that proof without revealing the private key. Knowing a public key does not let an observer create a valid signature. A relying party is the service checking your login. An authenticator is the component that manages and uses the credential.
During registration, the service requests a credential for its account. The authenticator creates a key pair scoped to that service, and the service records the public key and a credential identifier. The private key is not sent to the website as a login secret. A passkey provider may securely synchronize it across your devices; other credentials remain bound to particular hardware. These storage choices affect recovery and security assumptions.
During login, the server creates a challenge: fresh, unpredictable data for this attempt. The browser mediates communication with the authenticator. You may unlock its use with a device PIN, fingerprint or facial verification. That local action authorizes use of the credential; the website receives a signed response, not your fingerprint image. The server validates the signature, challenge, expected website identity and required user-verification information before establishing a session, which is its record of your signed-in state.
WebAuthn is the web standard supporting this process. Credentials are scoped to a relying-party identifier, usually based on the service’s domain. The origin identifies the requesting website by scheme, hostname and port. Browser and server checks connect the response to the expected service. A lookalike site at a different domain cannot simply request the legitimate site’s passkey and relay a reusable password.
Passkeys improve the login step but leave other boundaries to protect. Someone who controls an unlocked device, a signed-in session, account recovery or a synchronization account can create other risks. Recovery is the route used to regain access after losing a credential. Evaluate it alongside the main login. Permissions also remain separate: proving who signed in does not grant that person access to every record.
Follow a worked example.
Imagine a fictional library portal at https://reader.example. Mina registers a passkey there. Her phone manages private key K, and the portal stores matching public key P plus an identifier linking the credential to her account. K and P are labels for real cryptographic keys, not passwords a person should type or invent.
On Monday the portal issues random challenge C1. After Mina approves the phone’s prompt, the authenticator signs the required response data for that request. The portal uses P to verify the signature and checks that the challenge and website identity match its pending login. If all required checks pass, it creates Mina’s session. Each check serves a different purpose: a valid signature alone is insufficient if it belongs to the wrong attempt or site.
On Tuesday an attacker replays Monday’s response. The pending challenge is now C2, so the old response for C1 fails. Fresh challenges prevent recorded responses from being accepted as new logins when correctly validated.
Next, the attacker sends Mina to https://reader-example.net. Similar branding does not make this the same domain. Under correct WebAuthn checks, that page cannot obtain a usable assertion for reader.example merely because Mina clicks its sign-in button. However, if Mina instead gives the attacker access to her recovery account or an already signed-in session, this example’s passkey protection does not solve that separate problem.
Where people get stuck
A passkey is not simply a fingerprint stored by every website. Biometrics can unlock a local authenticator, while the service verifies a cryptographic response. Also avoid treating any page labeled passwordless as equivalent: emailed links and typed one-time codes have different security properties.
Now try it yourself.
1. Check the core idea
A server verifies a valid signature but accepts yesterday’s challenge during a new login. Is the check sufficient? What should it verify instead?
Reveal the answer & reasoning
No. A captured valid response could be replayed if the server accepts it outside the intended attempt. The server must validate the fresh pending challenge, the expected origin and relying-party identity, the signature and required authenticator flags, and reject consumed or expired attempts. Successful login still requires separate authorization checks before accessing protected resources.
Why this was added
The existing authentication lesson teaches identity versus permissions, and TLS teaches channel protection. Neither explains passkey registration, public-key challenge-response, domain binding, replay rejection or synchronization recovery risks. This fills that distinct practical security gap.