Passkey Is Still Too Confusing to Use
Posted3 months agoActive3 months ago
bogleheads.orgTechstory
calmnegative
Debate
40/100
PasskeysPassword ManagementSecurity
Key topics
Passkeys
Password Management
Security
The article discusses the difficulties of using passkeys, a passwordless authentication method, and the community shares their experiences and concerns about its usability and security.
Snapshot generated from the HN discussion
Discussion Activity
Moderate engagementFirst comment
8m
Peak period
8
0-3h
Avg / period
3.4
Comment distribution27 data points
Loading chart...
Based on 27 loaded comments
Key moments
- 01Story posted
Oct 7, 2025 at 8:08 PM EDT
3 months ago
Step 01 - 02First comment
Oct 7, 2025 at 8:16 PM EDT
8m after posting
Step 02 - 03Peak activity
8 comments in 0-3h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 9, 2025 at 10:33 AM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45510507Type: storyLast synced: 11/20/2025, 12:50:41 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
I have bitwarden on all of them. I can coordinate 2FA TOTP easily. I don't see passkey adding value right now, it's simply added an extra model, alongside the others, which doesn't even reliably work.
Given their non-migrating quality, I can't federate can I?
Easy and painless.
Passkeys have some benefits, but the major reason they exist is vendor lock-in.
TOTPs are handled the same way (stored on two Yubikeys).
We used password managers when 2FA allowed us to guarantee that even a leak of the passwords wouldn’t be that catastrophic. If you sync your passkeys to your password manager, anyone compromising it has full access to your accounts.
I might be getting older but my memory is still good enough to remember a couple of secure passwords (secure, as in: 20+ chars long random strings), one of them being a password to my KeePass database, and the other to the email account where I keep a backup copy of it.
I would hate to be locked out of my accounts only because I lost my phone or Yubikey.
https://www.smokingonabike.com/2025/01/04/passkey-marketing-...
> I don’t know what a “relying party” is, so I’m not sure exactly what this threat entails, but this statement really puts the Passkey spec authors in a bad light.
How can you hear something, not understand the terminology, and then use that as a basis for declaring the speaker "in a bad light"?
> To be very honest here, you risk having KeePassXC blocked by relying parties
to not cast the author in a bad light?
They are straight up threatening a well regarded open source password manager for implementing portability for passkeys.
What they’re saying is: the FIDO spec allows website operators to specify which passkey implementations they trust for authentication to their site. If your passkey implementation does not follow the spec around how it secures secrets and validates user auth flows, you risk that some sites will not trust your software as a viable passkey option.
As a comparison: imagine I made an HTTP client called “wurl”, and it was like curl but when users used it with authenticated requests, it emitted their credentials in plaintext logs on their laptop. Site operators could say “I’m gonna block requests where the user agent is wurl, because we don’t want our users to think they’re making secure requests and not catch this credential mishandling”.
No free software principles have been broken here: site operators (relying parties) are free to determine which auth implementations they are willing to interact with. Users are free to stop using sites that block auth implementations they think shouldn’t be blocked. No primitive of free software demands that site operators interoperate with something just because it’s a FOSS client.
https://grapheneos.org/articles/attestation-compatibility-gu... https://fsfe.org/activities/routers/
You’re welcome to want service operators to do that, but not doing it doesn’t affect any of your software freedoms.
The later half -- the freedom to change the program -- is meaningless in a world of attestation. Tivoization was explicitly forbidden on these grounds: if you can modify the software, but cannot use it in its modified state, the distributor is in violation of the spirit of free software and in particular, GPLv3.
It is a basic argument from positive liberty: the freedom for services to discriminate based on user's software and the freedom of the user to be discriminated against is no freedom at all.
Free software does not mandate service operators to interoperate between their own infrastructure and custom or modified software you possess. You are not somehow guaranteed access to someone else’s system just because your local code has a FOSS license.
The latter is what I mean. Web Integrity or SafetyNet are a closer counterpart to this situation than your curl example. A user agent is just a hint; attestation is an effective enforcement mechanism.
No Free Software license on my client can obligate your server to cooperate. But if attestation becomes the norm across many different services, the entire framework of user choice Free Software stands on collapses.
How would Ungoogled Chromium survive if every second website rejected non-Google Chrome? We've already seen this play out with Android: more people daily-drive GrapheneOS than Lineage because it passes Google's lower-level integrity checks.
And when a "strongly advised" government app requires the strictest attestation level, will you have to move countries just to exercise that freedom of choice you supposedly have?
In the same way that commercial entities aren't guaranteed a business model just because they want one, free software isn't guaranteed connectivity to other people's systems just because otherwise it's less useful.
In my mind, a passkey authenticates the device, while the password authenticates you, the user. Passkeys let us limit which devices are allowed to connect with our credentials. A hacker in Eastern Europe could steal my login, but if their laptop isn't authorized, it makes an account takeover much harder.
(Side note: This is also why I'm uncomfortable putting TOTP codes and passkeys in the same password manager as the regular login credentials. It effectively defeats the whole purpose, turning multi-factor authentication back into single-factor again.)