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.)
ggm•4mo ago
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?
mmiyer•4mo ago
ggm•4mo ago
grim_io•4mo ago
Easy and painless.
sph•4mo ago
Passkeys have some benefits, but the major reason they exist is vendor lock-in.
port11•4mo ago
akerl_•4mo ago
slau•4mo ago
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.