# Passkeys Block the Fake Login Page. So Where Did My Key Go? **Summary:** Passkeys shut down a familiar phishing trick, then leave users to guess who stores the credential and how recovery works. I would make them the default only when a service answers both questions. - Canonical: https://markhuang.ai/news/passkeys-stop-password-phishing-key-custody - Language: en - Author: [Mark Huang](https://markhuang.ai/about) - Published: 2026-09-18 - Section: News - Tags: Passkeys, WebAuthn, Account Security, Password Managers, Account Recovery - Source: [Ethan Hawksley](https://hawksley.dev/blog/i-dont-like-passkeys) - License: https://creativecommons.org/licenses/by-nc/4.0/ --- ![A glass passkey opens a secure doorway while paths behind it split toward a phone, laptop, tangled connectors, and a gated recovery vault](https://cdn.markhuang.ai/news/passkeys-stop-password-phishing-key-custody/hero.webp) *The login can be simple while the custody decision stays hidden. I want to know where the credential lives before I make it my only way back in.* In ["I don't like passkeys,"](https://hawksley.dev/blog/i-dont-like-passkeys) published on September 18, 2026, Ethan Hawksley argues that passkeys are an awkward trade for individuals who already use unique passwords and a separate TOTP app. They block the familiar fake-login-page attack, but they can also tie access to a device, a credential provider, or a recovery flow the user may not understand until something breaks. I agree with the diagnosis more than the verdict. Passkeys solve a problem that passwords never did, and I would not give up that phishing resistance. The trouble is that the product prompt usually sells a faster sign-in and skips the custody decision behind it. Before a service pushes me toward passwordless, I want to see where the passkey lives, whether I can add an independent backup, and what happens after I lose every synced device. Portability is also moving faster than the source gives it credit for. Bitwarden now documents direct passkey transfers through the FIDO Credential Exchange Protocol on [iOS 26 and later and Android 14 and later](https://bitwarden.com/help/storing-passkeys/), as long as both apps support the protocol. That is meaningful progress. It is not the same as every passkey being portable across every provider today. ## The cryptography is doing its job The case for passkeys is not marketing fluff. The [WebAuthn Level 3 specification](https://www.w3.org/TR/webauthn/) describes public-key credentials scoped to a relying party. The service stores the public key, while the authenticator protects the private key. Under the specification's security assumptions, later authentication is resistant to tampering by a man-in-the-middle attacker. A passkey created for the real site cannot simply be replayed at a lookalike domain. That changes the attacker's economics. A reused password can leak from one service and work on another. A password can also be handed to a convincing fake login page. A passkey is neither reusable across sites nor something a person can type into the wrong form. The [FIDO Alliance](https://fidoalliance.org/passkeys/) also distinguishes synced passkeys from device-bound ones, which matters because those two choices have different backup and portability properties. This is where I part company with Hawksley's conclusion. Comparing a passkey with a perfectly managed random password plus an independent TOTP code sets a high baseline. Plenty of people do not meet it. Even in the skeptical [Hacker News discussion](https://news.ycombinator.com/item?id=42442639) I read, one counterargument kept resurfacing: passkeys force site-specific credentials and make large-scale phishing less useful, even if device loss and recovery still need better answers. ## The key went somewhere The awkward part is that "create a passkey" sounds like one action, but it can produce different custody arrangements. The credential may sync through an operating-system account, live in a third-party password manager, or stay bound to a hardware key. Those are not cosmetic storage preferences. They decide which company account, device, or physical object becomes part of the login chain. Hawksley is right to press on hardware-key operations. A careful setup may require enrolling multiple keys on every important account, then tracking which sites know about which key. Discoverable credentials also consume storage on the key. His source points to capacities that vary by model, so buying one token does not end the planning problem. Synced passkeys trade that manual work for provider trust. Cross-platform credential managers can make the experience much better. An [Ars Technica field report](https://arstechnica.com/security/2024/12/passkey-technology-is-elegant-but-its-most-definitely-not-usable-security/) found that passkeys stored in 1Password worked across the author's devices and browsers, while also arguing that the extra provider layer was poorly explained to ordinary users. That mixed result sounds right to me. A credential manager can be the answer, but the login screen should not pretend there was no custody choice. ## Recovery is still the product A passkey can secure the front door while account recovery leaves a side window open. Google's own [passkey UX guidance](https://developers.google.com/identity/passkeys/ux/user-journeys) tells services to establish a recovery method when a passkey account is created. It lists possibilities such as phone, email, social login, or identity proofing, depending on the service. That guidance is practical, but it also confirms Hawksley's central point: WebAuthn does not decide who gets the account back after every credential is gone. This creates two opposite failure modes. A permissive fallback can restore access, but it can also preserve the phishable route that passkeys were supposed to remove. A strict fallback protects against takeover, but it can turn device loss or a provider lockout into permanent account loss. There is no universal setting that removes the tradeoff. Each service has to choose, explain, and support one. > **Info:** > > Before I make a passkey my default, I want five answers: where it is stored, whether I can register another independent passkey, whether my provider can transfer it, how I revoke a lost device, and which fallback can recover the account. What I keep looking for is visibility, and most passkey prompts give me almost none. Google recommends showing the source of each registered passkey in account settings, such as the device platform or third-party manager. I would put that information next to the creation prompt, then include backup enrollment and recovery review in the same flow. The security settings page is too late. Many people will never open it. ## My default is conditional I would use passkeys where the service lets me see and manage every registered credential, add an independent second path, and understand recovery before removing the password. I would hesitate when the prompt only says the new method is easier, especially if the platform account holding the synced passkey is itself hard to recover. For product teams, a successful WebAuthn ceremony is only the start. The account page needs clear provenance, support for multiple passkeys, revocation, and a recovery policy that does not quietly weaken the whole system. Nagging users to enable passkeys before those pieces are legible asks them to accept a risk transfer they cannot inspect. Hawksley's essay works because it refuses to confuse elegant cryptography with a complete login product. I am less pessimistic about portability, especially now that credential exchange is appearing in tools people can use. Still, I do not want a passwordless promise without a custody map. I will keep using passkeys, but only when I can trace the way back in.