The worst thing about passkeys is how browser extensions must handle them: using JavaScript injections to the web page. Of course this means _any_ browser extension could do the same and be the man-in-the-middle inspecting the passkey creation and authentication.
I'd be glad to have some kind of standard API behind a proper permission for handling passkeys.
The only thing that they should be able to intercept there, though, would be the specific passkey for the page you are authenticating with. With the specific challenge that was included, even. Such that it is not exportable to somewhere else for them to authenticate as you.
Sure, it sucks that anything is interceptable. But this is still an improvement over the status quo.
This post prompted me to give it a try at webauthn.io.
Passkey support is disabled by default, so you have to enable it in the settings for the browser extension. After that, the UI seems reasonable enough. It creates an entry with a "Passkey" tag, where the Password field is empty, and the credentials are stored as additional attributes on the Advanced tab.
One thing I'm not sure about: although the extension has a setting to fall back to the browser's own passkey support, when I dismissed the KeePassXC prompt, I did not get a prompt from Firefox.
Thank, I hadn't noticed that, I thought I had to wait for the extension to be updated after the announcement from KeepassXC.
> After that, the UI seems reasonable enough.
I tried it on webauthn.io and I'm wondering if there's a point in showing a prompt on every login attempt, if passkeys are phishing proof. Why not just allow the login right away? Maybe show a notification that it happened, but why wait for user confirmation?
This hasn't actually been released yet, it's just in the release branch. It was merged down less than 4 days ago. It comes with the following caveats:
> What is not working / is missing / won't be implemented:
> Some extensions are still missing (authentication doesn't support them at all, yet).
> Support for Resident Key.
> Support for triggering unlock from extension.
> Support for root certificates.
> Support for PIN/TouchID when authenticating.
> What is not tested:
> Support for Passkeys with Google/Apple and other common sites
So... can anyone confirm to me whether the passkey implementation in KeePassXC actually works with any of the sites implementing passkeys? I'll be happy if it ends being great and works everywhere. But what should I take away about the spec that the developers who have implemented the spec in KeePassXC aren't certain whether it will work with every site that claims to support passkeys?
I'm happy for KeePassXC to add support, it's a big deal, but it seems pretty early to say, "see the Linux situation is solved now." I go back to the complaint about passkeys being recommended for people to use today, even though they're still kind-of half finished. This is on a release candidate branch, and we're already acting like Linux is just supported now.
Never mind the fact that it's a partial implementation, never mind the fact that we have no idea if browsers like Chrome will allow KeePassXC to be treated as a platform provider without installing an additional extension to bypass the browser's built-in behavior. Never mind the fact that its import/export format only works with itself. Linux is supported now and you can export your keys, what's the problem? /s
----
And ignoring all of that, if Linux has support now, I would repeat: why do I need to find out about this on Mastodon? Seriously, the FIDO Alliance is made of the richest tech companies on the planet. Why is the official user-facing dev site -- a site maintained by W3C members and organizations -- giving incorrect information?
Why are supported features, goals, and timelines being communicated entirely via social media?
It's actually tested with Google. Apple does not work because they have restricted the Passkey creation outside the browser. And there's a list of tested sites in the pull request.
Linux situation is definitely not solved yet, and some sites still ignore Firefox because of missing support. The only reason I mentioned KeePassXC because it's the first free and open source solution that actually supports importing and exporting Passkeys. Even if it's still beta/rc phase.
Every other password manager browser extension injects same kind of scripts to every page (1Password included), because browsers lack an open API for WebAuthn.
Blegh... to be clear, I'm not trying to be snippy with you in specific, and you're right that it is a big deal for KeePassXC to add support. It's a step in the right direction. Sorry for the sarcasm.
I'm just frustrated about stuff like this:
> and some sites still ignore Firefox because of missing support
> Apple does not work because they have restricted the Passkey creation outside the browser.
> Every other password manager browser extension injects same kind of scripts to every page (1Password included), because browsers lack an open API for WebAuthn.
These are all failures of the FIDO Alliance. This is a really bad position for implementations to be in, and it is on the FIDO Alliance that doing things like restricting passkey creation isn't a blocker for certification. It's on the FIDO Alliance that there are recommendations going out from passkey providers that ordinary users should start using passkeys via browser extensions when there literally isn't an API for those extensions to hook into yet. If sites are blocking log-in from browsers even just via user-agents, that's on the FIDO Alliance for not shutting that crap down, especially in the occasional instances where the companies doing it are FIDO Alliance members.
Passkeys just aren't ready. It's a technology that is conceptually really cool that could in an alternate universe be easy to recommend as a full replacement for passwords -- but because it's getting rushed out with serious caveats and with a complete disregard to user autonomy and freedom or even just consistency between implementations, the first experience most users have with this is going to be awful.
Honestly, it's a failure of the FIDO Alliance that to talk about Linux support I need to know the difference between a hardware bound and roaming key; that is too much complication for a password replacement. Especially when the actual documentation about which platforms support what is basically nonexistent. It's just a giant incomprehensible mess.
----
To kind of emphasize the point: I can't give you a genuinely confident answer about whether or not Linux is intended to be able to support devices without gesture or biometric support. KeePassXC doesn't require this as far as I can tell, and nobody is shutting them down so maybe it's OK? But also there is no official acknowledgement outside of social media from the FIDO Alliance that this exists (at least, not that I can find anywhere), and from my own reading of the WebAuthn spec my instinct would have been that biometric/gesture support (validation of user presence) is a device requirement in the spec and that pins aren't a substitute.
Am I reading wrong? Is this just a part of the spec we're ignoring? Is KeePassXC doing something behind the scenes to get around that requirement? I don't know. Sure would be nice if there was an Alliance that could clarify those things in official documentation on a user-facing site. But I guess in the meantime I can settle for more Arstechnica and EFF articles about how you should consider using passkeys today...
Not your fault, it was good for you to point out KeePassXC. I just don't want people looking at that and saying, "oh, so the Linux situation is solved." It's not only not solved, I don't think I could give a fully accurate description of what the Linux situation even is or what the main problems are standing in front of it, because the current status of the blockers are ambiguous and messy, and the FIDO Alliance does not seem to think that is a problem that is has any obligation to care about.
