The passkey spec authors think websites should be able to ban clients which allow users to manage their own data[1,2]. It makes me really hesitant to adopt passkeys if my client could get banned because it's open source and lets me control my client how I want to. It appears to be more useful for vendor lock-in than anything else[3]. A shame, since it could've been a cool tech if they had built it to be resilient to this kind of abuse, but it's clear they think vendor lock-in is actually a core feature of the protocol.

[1] Spec author quote: "To be very honest here, you risk having KeePassXC blocked by relying parties." https://github.com/keepassxreboot/keepassxc/issues/10407#iss...

[2] https://www.smokingonabike.com/2025/01/04/passkey-marketing-...

[3] https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shatt...

▲

jeroenhd 3 hours ago | parent | next [-]

The point of passkeys is that they're unexportable. Software implementations like Bitwarden/KeepassXC/etc. making them exportable go right against the point of the protocols.

I personally think the ability to export+import passkeys is a good thing from a backup point of view, but he's not wrong in suggesting that companies actually using the high security features of passkeys will eventually block software implementations like these.

This isn't about vendor lock-in. Nobody is asking for KeepassXC to remove passkey support. This is about security software implementing an API and not fulfilling the expectations that come with such an implementation. To quote the comment you linked:

> That's fine. Let determined people do that, but don't make it easy for a user to be tricked into handing over all of their credentials in clear text.

▲

coldpie 3 hours ago | parent | next [-]

It's fine for them to make suggestions for projects to improve their software. The problem is threatening clients with being banned because they don't agree with those suggestions. If a website is able to ban me because of the passkey client I'm using, then I'm just not going to use passkeys. It's too unreliable.

> personally think the ability to export+import passkeys is a good thing from a backup point of view

It's not a "good thing," it's absolutely critical. If I can't back up my credentials in a location that I trust, then it's not an acceptable login method. What happens if my PC goes down and I couldn't export my data? I just can't log in anywhere? KeePassXC lets me do that, but the spec authors think it's appropriate to ban me for using it because it lets me manage my own data. That's bonkers.

▲

jeroenhd 3 hours ago | parent [-]

I don't see where he is threatening anybody? He's just stating the obvious. If you promise to store a key in a non-exportable format and then create a big export button, websites won't trust your software.

> What happens if my PC goes down and I couldn't export my data? I just can't log in anywhere?

Then you follow the procedure you would follow for when you'd forget your password. Probably a password reset through email, maybe calling customer support. Or if you have it set up, you could use the passkey set up on your phone or Yubikey or whatever to log in and create a new password on your new PC.

Passkeys aren't passwords, that's the whole point. It's modelled after the "something you have" factor, not "something you know". If you're finding workarounds to violate the security design, you're not gaining any advantage by using passkeys. Just use a password if you want to use a password.

▲

coldpie 3 hours ago | parent [-]

> If you're finding workarounds to violate the security design, you're not gaining any advantage by using passkeys.

The trouble is, if websites are allowed/encouraged to ban clients, then the advantages you're talking about come with the downside of hard-tying yourself to one of 3 US-based Big Tech companies, because those will be the only ones who will ship clients declared "secure." That's not a trade-off I'm willing to make for something as critical as my service logins. You can already see this happening, almost every article talking about passkeys assumes you're logging in with an Apple, Google, or Microsoft device.

> Then you follow the procedure you would follow for when you'd forget your password. Probably a password reset through email, maybe calling customer support.

This is a downgrade from passwords (and exportable passkeys), where I can just restore it from a backup.

> Just use a password if you want to use a password.

Yeah, that's what I plan to keep doing, unfortunately. What I'm worried about is a password-less future where that's no longer an option and we all have to submit to using one of Android, iOS, or Windows to log in to everything because those are the only clients that can be trusted(TM) to handle the user's data as the big tech companies and governments desire it to be handled. This is a dark future.

▲

an hour ago | parent | next [-]

[deleted]

▲

Magnusmaster 2 hours ago | parent | prev [-]

You already need to submit to iOS or stock Android for a myriad of banking or government apps that use remote attestation to verify that you are running "untampered" software.

Remote attestation is evil.

	▲	coldpie 2 hours ago \| parent [-]
		FWIW this has not been my experience in the US, I've always been able to use websites for these things. I use my phone for almost nothing important since I don't trust it. But yes, I fear we are heading in that direction too.

▲

stubish 2 hours ago | parent | prev | next [-]

But the natural result is vendor lock in. To stop exports of keys, sites will need a whitelist and secure method to verify the hardware or software implementation has not been tampered with. If an implementation is banned, the obvious solution is to allow it to pretend to be a non-banned implementation. Or admin level processes smuggling keys out of approved implementations. I don't think anyone wants an arms race, thus the vague threats to remove features that users are demanding before they will consider buying into the ecosystem.

▲

sigmar an hour ago | parent | prev | next [-]

Both things can be true:

1) that they're enforcing these specs for technical reasons, not because they want vendor lock-in

2) a result of these decisions in the long term is vendor lock-in

▲

nabogh 3 hours ago | parent | prev [-]

I agree with you but the whole thing makes me uncomfortable. We're definitely making it easier for these security conscious companies to do vendor lock in if we encourage passkey use.

▲

otterley an hour ago | parent | prev | next [-]

So if a client goes rogue someday (either intentionally or has been compromised) and starts shipping off private material to a third party, you think relying parties shouldn’t have the option not to trust that client anymore?

▲

yawaramin 4 hours ago | parent | prev [-]

Apple doesn't do attestation, so effectively this feature is dead in the water.

	▲	lelandbatey 3 hours ago \| parent [-]
		Per the article, Apple does do attestation. By default attestation is off unless you have enterprise management turned on. But the existence of attestation means Apple could at any time in the future make attestation on by default and suddenly our devices control our secrets more than we do.