Passkeys: A Shattered Dream — blog post by Firstyear

[erlend-sh]

Since Rauthy implements passkeys - and afaik uses webauthn-rs to do so - it seemed fitting to share today’s post by @Firstyear

https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shattered-dream/

At this point I think that Passkeys will fail in the hands of the general consumer population. We missed our golden chance to eliminate passwords through a desire to capture markets and promote hype. Corporate interests have overruled good user experience once again. Just like ad-blockers, I predict that Passkeys will only be used by a small subset of the technical population, and consumers will generally reject them.

I generally agree with this outlook. Passkeys are by no means useless, but I doubt their widespread applicability in consumer applications. They seem more fitting in the context of specific teams.

[sebadob]

So my take on this is that you should never use any kind of password / passkey store integrated into a platform like apple or android. The problem is that at that point, they simply own your identity anyway, can mess it up (like he described), or simply steal it. At that point, it is not better at all and something like bitwarden, which I use since many years now, will always be the safer alternative.

It was so easy, so accessible, I remember how it almost felt impossible. That authentication could be cryptographic in nature, but so usable and trivial for consumers. There really was the idea and goal within FIDO and Webauthn that this could be "the end of passwords".

Tbh, it is still ike this for me today... with Firefox.
When I log in with my passkey, Rauthy does not have resident key support and it will come with the problems of limited slots as he mentioned, I get the "Enter PIN Window" directly and that's it. But probably because I hardly refuse to use Chrome or any Google product at all.
However, I do have an Android phone and there it is extremely annoying I must confess. Google did not even implement PIN protected passkeys via NFC yet (and at this point, maybe they never will?). This is really a shame. So on Android, when I want to test things out, I am forced to either plug in my yubikey via USB (annoying) or use the built in "features". My phone is fully de-googled, so they don't really "own" my identity there, but it can get lost easily.
I am using Yubikeys exclusively, and they worked absolutely flawless for me so far.

However Chrome simply never implemented it leading to it being removed. And it was removed because Chrome never implemented it. As a result, if Chrome doesn't like something in the specification they can just veto it without consequence.

This alone is the reason why I don't even have Google Chrome installed on my OS for testing. When I want to check support there, I am using chromium and that's it, same engine underneath.

The dropped support for device attestation is not really problematic for Rauthy, but I totally agree from a business standpoint. And as always, Google faked it, said they were the good guys and are doing their own stuff under the hood with the mentioned feature flags. This is happening all the time and is the reason why the FedCM will be active with an experimental feature flag only.

In the beginning, Rauthy had its own authenticator App and I think with v0.3 of webauthn-rs I started adopting security and later passkeys with UV. But since the experience with webauthn was so good, I dropped it and got rid of the need maintaining it.
It was working really nice, but webauthn could just be used anywhere without the need to install an additional app.
This was a react native app, which I would never choose again, but nowadays Tauri v2 is in beta and probably not too far from stable. With v2 it bringts mobile support, which means we could have an authenticator again just as an addition and write it in Rust. But then you take a look at Google again, how they lock small developers out from their play store. I think now you have to be a company with at least 25 people working there if I remember correctly to "keep the standards hight".

But at this point, in Kanidm we are looking into device certificates and smartcards instead. The UI is genuinely better. Which says a lot considering the PKCS11 and PIV specifications. But at least PIV won't fall prone to attempts to enshittify it.

This is one of the reasons why I created Nioca. I don't have the time to push this further right now, because I have too much left for Rauthy currently, but I am using mTLS certificates and all that stuff a lot as well. They even work for user authentication really nicely and are so much safer than cookies and all that stuff. The only problem is the UX. It's not too easy for "normal people" to get them running.
I have a lot of pretty cool ideas for Nioca to make it more accessible for the average user, but not enough time.

Just as a side note: I took a quick look at a Rauthy instance which is running since quite a long time now. It currently has ~150 users and expect for very few, all of them are using password only accounts. People just don't care. They want their normal, most probably used everywhere default password, and that's it, sadly.

[Firstyear]

It was so easy, so accessible, I remember how it almost felt impossible. That authentication could be cryptographic in nature, but so usable and trivial for consumers. There really was the idea and goal within FIDO and Webauthn that this could be "the end of passwords".

Tbh, it is still ike this for me today... with Firefox.

Only on linux. Firefox on mac or windows both use the platform api rather than the inbuilt CTAP2 only authenticator-rs.

When I log in with my passkey, Rauthy does not have resident key support and it will come with the problems of limited slots as he mentioned, I get the "Enter PIN Window" directly and that's it. But probably because I hardly refuse to use Chrome or any Google product at all. However, I do have an Android phone and there it is extremely annoying I must confess. Google did not even implement PIN protected passkeys via NFC yet (and at this point, maybe they never will?).

They specifically try to avoid "activating" the security key in a lot of flows too.

This is really a shame. So on Android, when I want to test things out, I am forced to either plug in my yubikey via USB (annoying) or use the built in "features". My phone is fully de-googled, so they don't really "own" my identity there, but it can get lost easily. I am using Yubikeys exclusively, and they worked absolutely flawless for me so far.

However Chrome simply never implemented it leading to it being removed. And it was removed because Chrome never implemented it. As a result, if Chrome doesn't like something in the specification they can just veto it without consequence.

This alone is the reason why I don't even have Google Chrome installed on my OS for testing. When I want to check support there, I am using chromium and that's it, same engine underneath.

The broader issue is that google can just veto improvements to webauthn if they don't like them, since FF is asleep at the wheel.

Just as a side note: I took a quick look at a Rauthy instance which is running since quite a long time now. It currently has ~150 users and expect for very few, all of them are using password only accounts. People just don't care. They want their normal, most probably used everywhere default password, and that's it, sadly.

Most of the Kanidm users seem to be going toward our passkey services, but we also go to extreme lengths in webauthn-rs and Kanidm to avoid the issues that plague passkeys generally, even if we can't resolve all of them. But we also plan to go toward mtls and PIV as you did with nioca.

[sebadob]

Only on linux. Firefox on mac or windows both use the platform api rather than the inbuilt CTAP2 only authenticator-rs.

Okay, got it. I guess chromium does the same then (on Linux), right? Because it behaves the exact same way. Since I am a Linux only user, this explains it. It's a shame that they always try to force you into their own stuff and you have to put in more work just to get what you want. But I guess it will always be like that. I stopped self-hosting E-Mail servers as well because of annoying behavior of "the big ones".

They specifically try to avoid "activating" the security key in a lot of flows too.

I guess technically everything is working, they just don't want to. I had high hopes when they finally announced the support last September, only to find out that it's just partial and does not really solve my issue.

The broader issue is that google can just veto improvements to webauthn if they don't like them, since FF is asleep at the wheel.

Which will not change as long as most people are using their products anyway, sadly.

Most of the Kanidm users seem to be going toward our passkey services, but we also go to extreme lengths in webauthn-rs and Kanidm to avoid the issues that plague passkeys generally, even if we can't resolve all of them. But we also plan to go toward mtls and PIV as you did with nioca.

I really like the webauthn-rs crate, you have done great work with it. Thanks a lot!
Usually, mTLS is the best UX you can get, once the certificate is installed. Installing it is pretty easy these days as well. I just have a download button in the UI, you get a PKCS12 with a password you can see directly, and you can just click the download and all current OS'es should be able to import the certificate automatically.
Where I don't have a nice solution found yet is when a "normal user" has to exchange an expired client certificate. At least on Linux, the OS / Browser does not make it easy for you to import it and "automatically delete" the old one. This is a manual task.
If I could solve this, mTLS would be the nicest thing to use and we would be back to the easy and fast passkey flow from the beginning.

I planned on integrating Nioca with Rauthy so you could optionally have TLS and SSH certificates as well from one place as opt-in, but its a lot of work to do all of that in your free time.

Btw I didn't know about your blog before, but I will for sure continuing to read it. I like the content a lot.

[Firstyear]

Only on linux. Firefox on mac or windows both use the platform api rather than the inbuilt CTAP2 only authenticator-rs.

Okay, got it. I guess chromium does the same then (on Linux), right? Because it behaves the exact same way. Since I am a Linux only user, this explains it. It's a shame that they always try to force you into their own stuff and you have to put in more work just to get what you want. But I guess it will always be like that. I stopped self-hosting E-Mail servers as well because of annoying behavior of "the big ones".

Nope, Chrome and Chromium use their own internal drivers on all platforms.

They specifically try to avoid "activating" the security key in a lot of flows too.

I guess technically everything is working, they just don't want to. I had high hopes when they finally announced the support last September, only to find out that it's just partial and does not really solve my issue.

Yeah. It was contributed by someone from my workplace and mozilla dragged their feet to review it for about a year. very sad. :(

Most of the Kanidm users seem to be going toward our passkey services, but we also go to extreme lengths in webauthn-rs and Kanidm to avoid the issues that plague passkeys generally, even if we can't resolve all of them. But we also plan to go toward mtls and PIV as you did with nioca.

I really like the webauthn-rs crate, you have done great work with it.

Thank you. That means a lot to me today especially <3

And I'm very happy to see my work being used to enable people like yourself to create new and interesting IDPs. So well done with Rauthy!

Thanks a lot! Usually, mTLS is the best UX you can get, once the certificate is installed. Installing it is pretty easy these days as well. I just have a download button in the UI, you get a PKCS12 with a password you can see directly, and you can just click the download and all current OS'es should be able to import the certificate automatically. Where I don't have a nice solution found yet is when a "normal user" has to exchange an expired client certificate. At least on Linux, the OS / Browser does not make it easy for you to import it and "automatically delete" the old one. This is a manual task. If I could solve this, mTLS would be the nicest thing to use and we would be back to the easy and fast passkey flow from the beginning.

I planned on integrating Nioca with Rauthy so you could optionally have TLS and SSH certificates as well from one place as opt-in, but its a lot of work to do all of that in your free time.

I'm thinking about similar in Kanidm, I'm looking heavily into the rust-crypto ecosystem now. I have already worked with the rust TPM (tss-esapi) and pkcs11 authors on that front to pursue hardware bound keys, and I've just started with PIV. I really want to do this "right" by hardware binding keys :)

Btw I didn't know about your blog before, but I will for sure continuing to read it. I like the content a lot.

Thanks! Do you have a blog of your own?

[sebadob]

Nope, Chrome and Chromium use their own internal drivers on all platforms.

Out of curiosity, I booted up an older windows machine I keep around for testing. I tested with Firefox and Chrome using my local Rauthy instance. Both browsers behave in the exact same way as they do on Linux. I enter my E-Mail and when I get the webauthn request, I immediately see the "Enter PIN" window without anything in between. There is no difference in behavior. Am I missing something?

And I'm very happy to see my work being used to enable people like yourself to create new and interesting IDPs. So well done with Rauthy!

Thank you! :)

I'm thinking about similar in Kanidm, I'm looking heavily into the rust-crypto ecosystem now. I have already worked with the rust TPM (tss-esapi) and pkcs11 authors on that front to pursue hardware bound keys, and I've just started with PIV. I really want to do this "right" by hardware binding keys :)

Yes I have HSM keys on the TODO for Nioca since a long time, but it does what it should do now and all other things will come when I have more free time (haha, good one... :D ). Currently it handles software CA's only, but at least they are strongly encrypted and after a fresh start, you have to unseal it kind of like the hasicorp vault does it. From that point on, they will only be kept in-memory and never written to disk / database. So I would say it is as secure as it can be with non-HSM keys.

Or do you mean hardware keys on the client side? So basically

• get a client X509
• push it to your yubikey
• use yubikey to authenticate inside the browser

.. ?
That would be absolutely awesome, if something like that would be possible.

Thanks! Do you have a blog of your own?

No I don't. Every time I think about creating one, I end up doing something else from my very long TODO list of projects and ideas.
There is just so much time unfortunately.

[polarathene]

Or do you mean hardware keys on the client side? So basically

• get a client X509
• push it to your yubikey
• use yubikey to authenticate inside the browser

.. ? That would be absolutely awesome, if something like that would be possible.

That seems to be what this article with Smallstep demonstrates?:

We’ll bring together YubiKey’s Personal Identity Verification (PIV) and device attestation capabilities, a private ACME server running the new device-attest-01 challenge type, and a client certificate for mutual TLS.

...

If you’ve followed along, you should have a web server up and running.

• Insert your YubiKey, open a browser, and go to your Caddy server.
• You’ll be presented with a certificate dialog, and you should be able to select your client certificate from the YubiKey. The browser may ask for your YubiKey PIN, as a second factor.
• Once you see the “Hello world” message from Caddy, you’re in.

There's a related article from 2020 regarding short-lived SSH certificates provisioned with SSO login with their step ssh command.

[Firstyear]

Nope, Chrome and Chromium use their own internal drivers on all platforms.

Out of curiosity, I booted up an older windows machine I keep around for testing. I tested with Firefox and Chrome using my local Rauthy instance. Both browsers behave in the exact same way as they do on Linux. I enter my E-Mail and when I get the webauthn request, I immediately see the "Enter PIN" window without anything in between. There is no difference in behavior. Am I missing something?

Does the machine have bluetooth? TPM? I think that affects things.

And I'm very happy to see my work being used to enable people like yourself to create new and interesting IDPs. So well done with Rauthy!

Thank you! :)

I'm thinking about similar in Kanidm, I'm looking heavily into the rust-crypto ecosystem now. I have already worked with the rust TPM (tss-esapi) and pkcs11 authors on that front to pursue hardware bound keys, and I've just started with PIV. I really want to do this "right" by hardware binding keys :)

Yes I have HSM keys on the TODO for Nioca since a long time, but it does what it should do now and all other things will come when I have more free time (haha, good one... :D ). Currently it handles software CA's only, but at least they are strongly encrypted and after a fresh start, you have to unseal it kind of like the hasicorp vault does it. From that point on, they will only be kept in-memory and never written to disk / database. So I would say it is as secure as it can be with non-HSM keys.

Or do you mean hardware keys on the client side? So basically

* get a client X509

* push it to your yubikey

* use yubikey to authenticate inside the browser

Both, TPM/HSM for the CA server side, and yubikeys for the client :) I wrote a yubikey piv manager tool on a recent flight that I need to publish. I've just been reading the mozilla CA requirements to understand what I need to do to make a "good" CA too.

[sebadob]

Does the machine have bluetooth? TPM? I think that affects things.

Nothing like that. And it does have a local account, not the Microsoft one. Probably something like that then. -.-

Both, TPM/HSM for the CA server side, and yubikeys for the client :) I wrote a yubikey piv manager tool on a recent flight that I need to publish. I've just been reading the mozilla CA requirements to understand what I need to do to make a "good" CA too.

mTLS in the browser with certs from a yubikey sounds so awesome.
If you plan on open sourcing this tool, I'd be glad to help out with testing or contributing!

I have plans to go on with my Nioca project as well as soon as I have more time.

[Firstyear]

Both, TPM/HSM for the CA server side, and yubikeys for the client :) I wrote a yubikey piv manager tool on a recent flight that I need to publish. I've just been reading the mozilla CA requirements to understand what I need to do to make a "good" CA too.

mTLS in the browser with certs from a yubikey sounds so awesome. If you plan on open sourcing this tool, I'd be glad to help out with testing or contributing!

Of course :) I'll be putting it into Kanidm somewhere.

I have plans to go on with my Nioca project as well as soon as I have more time.

Sounds good. I'm not planning to lock anything into a single CA at this point, so you should have no issue with nioca and the yubikey stuff. I was probably still gonna make my own CA as I have some weird high-security enterprisey requirements I want to meet.

[sebadob]

... as I have some weird high-security enterprisey requirements I want to meet

I usually have these requirements from my own wish list. I like that a lot. :D
I will probably buy a Yubi HSM as well at least for some testing and playing around with it. I am just a big fan of TLS certificates in general, as you can do a lot with them and the chain of trust makes them really powerful and flexible, as long as you trust some root CA.

Looking forward to your release! :)

[Firstyear]

Okay, maybe we'll be able to collaborate some more then on it :)