Engineering
I want to be clear about where I'm standing before I start listing problems: passkeys are the most significant improvement in consumer authentication in twenty years. Phishing resistance as a structural property rather than a training exercise. No shared secret to breach. No reuse across sites. If y
Engineering
Most WebAuthn explanations stop at the conceptual level: a keypair is created, the private key stays on the device, the server verifies a signature. That's correct, and it's roughly a tenth of what you need to implement a relying party without introducing a vulnerability.
Engineering
Passkeys are explained badly almost everywhere. The usual description — "you log in with your face instead of a password" — isn't merely imprecise, it describes something that isn't happening. Your face is not sent anywhere. It isn't the credential. It's barely part of the protocol.
Engineering
Here is a claim you will find on nearly every passkey landing page, including some very good ones: passkeys are phishing-resistant, unphishable, unreusable, and not vulnerable to credential stuffing. All of that is true.
Engineering
There is a moment in most WebAuthn implementations when someone reads the spec, discovers attestation, and gets excited. It sounds like exactly what a security-conscious team wants: cryptographic proof of what kind of authenticator the user registered. Not a claim, not a user-agent string — a signat
Engineering
There is a specific failure that no security architecture diagram contains.
Implementing MFA
A hands-on report from adding SMS as a second factor to a live identity provider: 17 Java classes and two silent bugs on Keycloak vs. a single toggle on ClavionX.