Passkey is still too confusing to use(bogleheads.org)
bogleheads.org
Passkey is still too confusing to use
https://www.bogleheads.org/forum/viewtopic.php?t=461846
27 comments
I use passkeys exclusively on my YubiKeys, and I ensure I always have a backup (two Yubikeys with one passkey each).
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.
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.
FWIW Bitwarden supports passkeys which allows you have them synced across all your devices.
This is the way.
Easy and painless.
Easy and painless.
I use Bitwarden. I need none of the convenience of passkeys, and I am able to login on a third system just by hand-copying a password, which I cannot do with passkeys. So why should I prefer passkeys anyway?
Passkeys have some benefits, but the major reason they exist is vendor lock-in.
Passkeys have some benefits, but the major reason they exist is vendor lock-in.
Thank you. TIL.
I'm not a security expert, but I have an opinion on passkeys: I think we should stick to using them only for 2FA. At least for any site where the security really matters.
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.)
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.)
Criminals love getting persistent access to accounts using Passkeys because there's a large populous that do not understand what a Passkey is or does or review if they have any, and even if they have an unauthorised one created, do not do anything about it.
Call me old fashioned but I distrust any form of authentication that is tied to a specific device.
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.
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.
Most passkeys are synced to multiple devices.
This is great until you get a memory altering brain injury. Then what?
That's why I have those passwords written down on a piece of paper that I keep in my desk drawer :) /s
KeePassXC can now generate, store and export Passkeys.
It also feels like many sites are trying to either trick or gaslight me into moving over to a passkey. Amazon was successful in tricking me, and I’ve had to be much more vigilant since that happened.
That's because for the average user of most popular websites, user account takeover via weak passwords and phishing are massive risks. These sites are funneling their users hard towards passkeys because they're a huge step forward towards covering those risks.
Passkeys are also incompatible with Free Software:
https://www.smokingonabike.com/2025/01/04/passkey-marketing-...
https://www.smokingonabike.com/2025/01/04/passkey-marketing-...
This whole post just reads like somebody trying to axiomatically derive what passkeys are and how they work by hopping between fragments of blog posts, github issues, and other random docs. Sentences like this really drive that home:
> 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"?
> 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"?
Why do you need to know what “relying party” could mean for
> 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.
> 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.
This is why knowing what technical terms mean matters.
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.
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.
Users should have the freedom to choose their implementations, or the entire point of Free Software is nullified and becomes useless. Take a look at what is happening with the Android attestation APIs, users of GrapheneOS (a libre and more secure variant of Android) are blocked from running mandatory government apps or almost mandatory banking apps, or even just fast food apps. Or the FSFE Router Freedom campaign. Or the mobile networks blocking devices that can share their access with other devices, or other devices they don't like.
https://grapheneos.org/articles/attestation-compatibility-gu... https://fsfe.org/activities/routers/
https://grapheneos.org/articles/attestation-compatibility-gu... https://fsfe.org/activities/routers/
Service operators being required to allow users to use whatever software the user wants to interact with the operator’s system is not in fact a principle of Free Software.
You’re welcome to want service operators to do that, but not doing it doesn’t affect any of your software freedoms.
You’re welcome to want service operators to do that, but not doing it doesn’t affect any of your software freedoms.
Freedom 1: The freedom to study how the program works, and change it to make it do what you wish.
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.
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.
I think we’re just speaking different languages here.
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.
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.
If I said the Web Integrity API is incompatible with Free Software, would you read that as:
a) Chromium would cease to be Free Software if it implemented it; or
b) Web Integrity itself makes effective Free Software structurally impossible and exists to punish its users?
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?
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?
Ungoogled Chromium is still free software even if every second website rejects it. Free software does not have a de facto right to interoperate, and does not become less free or structurally impossible because other entities don't interact with it. The freedoms define what you can do to and with software you possess; it does not put requirements on 3rd parties to interact with you.
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 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.
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?