Passwords vs Passkeys: How Modern Sign-In Actually Works

A password and a passkey may appear in the same sign-in screen, but they rely on different security models. A password is a reusable secret you know and send to a service. A passkey uses public-key cryptography: a private key stays with your passkey provider, while the service stores the matching public key. Sign-in proves control of the private key without revealing it.

That difference removes several common password problems, but it does not make the rest of the account invulnerable. Device security, passkey-provider recovery, application implementation, and account recovery still matter. The useful comparison is therefore not passwords bad, passkeys perfect. It is which attacks each design prevents and which responsibilities remain.

How password sign-in works

When you create a password, a properly designed service does not need to store the plain password. It stores a result produced by a password-hashing process with a unique salt. During sign-in, the service processes the password you enter and compares the result. If an attacker tricks you into entering the password on a look-alike site, however, the attacker receives the reusable secret and can try it on the real service.

Reuse makes the damage spread. If the same password protects several accounts, one exposed credential can be tested elsewhere through credential stuffing. Unique passwords generated and saved by a password manager limit that spread. Multi-factor authentication adds another barrier, though codes that a user can type into a phishing page can also be relayed by an attacker.

What a passkey contains

A passkey is a FIDO credential associated with an account at a particular website or application. During creation, the authenticator generates a cryptographic key pair. The public key is registered with the service. The private key is protected by a passkey provider on a device, security key, operating-system credential manager, or compatible third-party manager.

Unlocking the device with a PIN, fingerprint, face check, or pattern authorizes use of the private key. The biometric check normally happens locally; the service receives cryptographic proof, not the fingerprint or face data. The FIDO Alliance passkey overview describes passkeys as cross-platform FIDO credentials used through the same action that unlocks a device.

How passkey sign-in works

1. The service sends a fresh cryptographic challenge to the browser or application.
2. The authenticator confirms that the request belongs to the registered service and asks for user consent or device verification when required.
3. The private key signs the challenge locally.
4. The service verifies the signature with the public key it already stores.
5. The fresh challenge prevents an old response from being reused for a new sign-in.

The web mechanism is standardized through WebAuthn. The W3C Web Authentication specification defines credentials scoped to a relying party and mediated by the browser and authenticator. This origin binding is central to phishing resistance: a credential registered for one service is not offered to an imitation domain.

What passkeys improve

• No reusable password is sent during sign-in.
• Each service receives a different credential, removing password reuse between sites.
• A phishing page on another origin cannot request the credential registered to the legitimate service.
• A server breach exposes public keys rather than a password database that can be cracked and reused.
• Device unlock can replace memorizing and typing a complex secret.

What passkeys do not solve by themselves

• A compromised or unlocked device may still expose an active session or allow credential use.
• Malicious browser extensions, application flaws, and session theft exist outside the passkey protocol.
• Weak account recovery can bypass a strong sign-in method.
• Losing access to every device and recovery method can still lock the user out.
• A user can still be deceived into authorizing a harmful action after a legitimate sign-in.

FIDO guidance emphasizes that full phishing resistance includes enrollment and recovery, not only the normal sign-in step. A service that lets an attacker reset the account through a weak fallback has moved the weak point rather than removed it.

A practical migration plan

1. Create passkeys for important services that support them, then confirm where those passkeys are stored and how they sync or remain device-bound.
2. Add more than one recovery path when the service allows it, such as a second trusted device or hardware security key.
3. Keep unique passwords in a password manager for services that still require passwords.
4. Enable the strongest available second factor for remaining password accounts, preferring phishing-resistant methods where possible.
5. Store recovery codes offline in a place you can reach if your main device is unavailable.
6. Review old devices and active sessions after replacing or losing a device.

Passkeys are a meaningful improvement because they change the protocol, not merely the shape of the secret. Adoption will remain mixed for some time, so most people need both systems: passkeys where supported, and strong unique passwords with appropriate multi-factor protection everywhere else.

Primary references

FIDO Alliance: Passkeys. W3C: Web Authentication specification.