Passkeys and WebAuthn: Ending the Password Era in Modern Web Apps
The cryptographic key-based authentication standard eliminates an entire class of phishing and credential-stuffing attacks, but deploying it demands carefully designed account recovery.
Passwords have a flaw that complexity rules or periodic rotation cannot fix: they are a shared secret that must be transmitted to be verified. Every transmission is a chance for theft. Passkeys remove the problem at its root.
Why phishing becomes structurally impossible
Passkeys use cryptographic key pairs. The private key never leaves the user's device; all that travels to the server is a signature over a random challenge. There is no secret to steal in transit, because no secret is sent.
The most decisive part is the one most often left out of the discussion: the key is bound to the domain name where it was created. A browser refuses to use a passkey belonging to one domain on another, even when the site looks identical. A user tricked into opening a fake site still cannot hand over their credentials, because the browser will not offer them at all.
What changes for developers
The registration flow replaces storing a password hash with storing a public key plus a credential identifier. The login flow replaces hash comparison with verification of a signature over a server-generated challenge.
A few things are mandatory. The challenge must be truly random and valid only once. The origin value in the response must be verified against the expected domain. The signature counter, where the device provides one, helps detect credential cloning.
A single account should be able to hold several passkeys at once. Users who work across a phone and a laptop will register both, and forcing a single credential creates needless recovery problems.
The hardest part is recovery
This is what decides whether a deployment succeeds. A user who loses all their devices loses all their passkeys, and there is no "forgot password" link to click.
Passkeys synced through an operating system provider significantly reduce this risk, because credentials are restored along with the device account. But a system still has to offer a path for users who do not use sync.
A common choice is to keep several methods on file: passkeys on more than one device, single-use recovery codes stored in hashed form, or a verified email as a fallback. It is worth recognising that the fallback path sets the real security ceiling — a passkey system with SMS-code recovery is only as safe as SMS itself.
A realistic transition
Switching passwords off overnight rarely goes smoothly. A staged approach that has proven itself: offer passkeys as an addition, prompt for registration when the user signs in, and once most active users have one, stop accepting new password registrations.
Measure adoption, not availability. A feature that is available but unused prevents not a single attack, and every benefit of passkeys only materialises once passwords are truly no longer a legitimate way in.
Budi Santoso
Contributing EditorSenior Software Architect dan pemerhati ekosistem PHP, cloud computing, dan performa web skala besar.
Related Articles
Lihat Semua →Software Supply Chain Attacks: Auditing Package Manager Dependencies
09 Sep 2026
Post-Quantum Cryptography (PQC): The Shift to Quantum-Resistant Encryption
02 Sep 2026
Mitigating SSRF and DNS Rebinding Attacks in Modern Web Architectures
25 Aug 2026
AI Agents and Tool Calling: Why Orchestration Is Harder Than the Model
20 Sep 2026