I don't like passkeys
My Grievances with Passkeys
For several years, the technology sector has been aggressively marketing passkeys as the definitive answer to the problem of authentication.
"Big Tech companies constantly nudge users during sign-in, insisting that passkeys are the more effortless and streamlined choice."
To stop these prompts, users must either surrender to the setup process or hunt through complex menus to disable them. For instance, Google utilizes the phrasing Skip password when possible, while Microsoft actively encourages a completely password-based passwordless existence.
The Technical Appeal
From a security standpoint, passkeys are impressive. Because they are cryptographically bound to a specific domain, they are immune to phishing via fraudulent login pages. Furthermore, they utilize asymmetric cryptography:
Because the server only holds the public key, a data breach does not expose the credentials needed to access the account.
The Corporate vs. Personal Divide
While this architecture is ideal for a controlled corporate setting, it is often a poor fit for the average person. The primary threats to an individual aren't always sophisticated hackers, but rather:
- Permanent account lockouts
- Automated system bans
- Physical loss of devices
By adopting passkeys, you trade protection against man-in-the-middle (AiTM) attacks for a higher risk of losing your account entirely. Moreover, passkeys create a false sense of security because the overall strength of an account is still limited by its weakest recovery link (e.g., SMS or security questions).
Comparison: Traditional vs. Passkey
| Feature | Traditional Password | Passkey |
|---|---|---|
| Phishing Risk | High | Negligible |
| Server Breach Risk | High (if poorly hashed) | Low (Asymmetric) |
| Recovery Ease | Moderate | Difficult/Fragile |
| Portability | High (Plain text) | Low (Bound to device/OS) |
The Hardware Key Dilemma
Hardware keys offer high security, but they come with significant friction. You cannot "back up" a passkey from a hardware device; you can only add or remove them.
The resulting workflow is cumbersome:
- Purchase 2-3 separate hardware keys.
- Manually enroll every single key on every single website.
This is expensive and doesn't scale. Furthermore, many keys use discoverable credentials (allowing the site to find your username), but these have strict storage limits:
- Minimum: 25 accounts per key.
- Maximum: Up to 300 accounts on high-end models.
Once you hit that ceiling, you are forced to either delete old accounts or buy more hardware.
The "OS Trap" (Synced Passkeys)
Apple and Google prefer your identity to be anchored to their ecosystems. Their "happy path" involves syncing passkeys to your primary OS account.
If an automated system bans your Google or Apple account, you lose access to every third-party account tied to those synced passkeys. While the FIDO alliance is attempting to standardize exports to fix this fragmentation, the current state is too immature for critical reliance. A password, by contrast, is simply a string—like CorrectHorseBatteryStaple—that can be manually backed up.
Third-Party Management Struggles
Using managers like Bitwarden or KeePassXC often feels like fighting the operating system. Even with new APIs like Android's Credential Manager, the user experience lacks the polish of traditional password autofill, especially within native apps.
The "Foreign Device" Problem
Passkeys work great on your own gear, but they fail in shared environments. If you need to use a colleague's computer:
- Hardware Keys: You might not have the right ports.
- Synced Keys: You have to trust the machine not to leak your credentials.
- Hybrid Transport: This involves scanning a QR code and using Bluetooth. In practice, this is plagued by connection failures and unsupported hardware.
Final Verdict: Not Ready for Prime Time
Passkeys are a great leap forward for people who previously reused the same password everywhere, and they make sense for enterprises. However, for the individual, the risk of lockout is more pressing than the risk of an AiTM proxy attack.
My recommended security stack:
- Randomly generated passwords
- Third-party password manager (for control/export)
- Independent TOTP application
This combination provides robust security without sacrificing the flexibility of plain text.