If you really want passkeys, put them in a password manager you control. But don't use a platform controlled passkey store, and be very careful with security keys.
Amazing article. Lots of great inside baseball. I'm a big proponent of hardware security keys, the whole pass key thing didn't make sense to me. Especially the resident keys. If you user workflow is terrible, nobody is going to use them. Which is even worse than not existing
The hardware keys are great but so far don’t have enough storage. For example, Yubikey as a second factor dynamically generated its responses, but now that it’s storing them it’s very limited to at most 25. It’s a known issue that will be solved though.
My biggest problem with hardware keys are replacement. If I lost one of my keys and get a replacement I would now need to go to a hundred sites and enroll the new key (and remove the old one). Until this workflow is automated I can only reasonably use hardware keys with a small number of "critical" accounts.
So for 99% of sites I'm going to use a synced software key.
I admit that passkeys have never made sense to me. You still have a username and password, but you’ve added a middleman who manages the password. Why not just use a password manager (without MFA, another useless annoyance)?
Passkeys are not passwords.
When you authenticate using passkeys you will proof that you have the secret (passkey), but you will never reveal that secret to the service you are authentication against.
So even if someone is able to steal that package containing the answer, that answer will not be valid a second time.
I’m sorry, but this still sounds as much like “Mares eat oats” as it did when I first heard it a decade ago. You still enter a username and password somewhere (ideally in your password manager) to gain access to your account.
Passkeys are. more similar to TOTP codes than passwords. Everything about passkeys is autogenerated. Browser negotiates with website to generate a key pair that will establish your identity on that site. Every time you "login" they exchange unique autogenerated keys to prove to each other who they are. That's it. You never have to remember anything again and it's impervious to many attacks that affect passwords and 2fa codes.
Where they fucked up is allowing big tech to call the shots so now instead of simply having passkeys in your browser you have to go to a higher authority to have them validated. And goes who that is — Google, Microsoft, Apple. So it's basically gatekeep and you can't touch them without depending on them.
How is that different from mutual TLS authentication?
Edit: It seems like OPAQUE just initiates mutual TLS authentication after the TLS session has already been negotiated with PKI. So it basically just allows websites to design their own login page instead of the one designed by the web browser.
I also find passkeys to be underwhelming and hope they don't catch on. It seems like a huge mire of complexity for very little gain. It seems like there are two main goals here:
Don't sent secrets to the sever.
Stop phishing.
Both great goals. However I wonder if we threw out the baby with the bathwater with passkeys.
A password manager is already a huge step to blocking phishing, because if the password doesn't auto-fill you get super suspicious. If you push your user to randomly generate their passwords then they also don't remember them so would have to look them up, then copy them over. If you are worried about users who are a risk to themselves you can make the route to extract a password from the password manager as complicated as you like.
As for not sending secrets to the server I think using a PAKE would have been a great option. If this was paired in a browser-integrated password manager it could be very secure. Think about some type of form field that can be filled with a password that isn't accessible to the page itself. The browser would then tag the password as PAKE and never expose it to the page again.
Another cool think able PAKE is that they can also authenticate the server. TLS-integrated SRP was very cool like this as you could have a self-signed certificate but verify it by entering your username and password. The UX may not have been good enough for public sites but it was an amazingly easy and secure option for private sites. This would actually be more secure than a PKI signed certificate as you aren't risking CA compromise. That being said integrating this with browsers with good UX may be quite difficult. I would love to see it.
But the biggest thing we lost was understandability. Even my grandmother understood what a password is. She knew how to back it up, how to transfer it to a new device. She could use it in two different browsers without setting up some multi-browser sync tool. She could write it in a notebook and log in at the library computer.
I really think that we should have just iterated on passwords. Switch to a PAKE and keep improving password-manager UX and pushing most users to auto-generated passwords. So much was lost by switching to a system that most users don't understand.
Glad to see another person who is not keen on the passkeys. I have the feeling it is being hyped and perhaps without good reasons. Therefore I was glad to share this blog post when I saw it on Mastodon. btw, the blog post author turns out to be the software developer of similar software like Authentik and Keycloak. In other words, not just the average Linux user :)
I really think that we should have just iterated on passwords. Switch to a PAKE and keep improving password-manager
UX and pushing most users to auto-generated passwords. So much was lost by switching to a system that most users
don’t understand.
When I search with a search engine for PAKE I don't find anything useful. Got a link ?
I like your reasoning about just using passwords. However, my experience is that a scary amount of users are using the same rather weak password for lots of different accounts. And a still scary amount of users does get tricked into phishing emails. What I like for myself is have a bunch of security keys and use them as much as possible for important logins.Some applications allow for five different security keys to be configured.And this could theoretically also be a way to use 2FA within teams. One team person does the login, adds a key, then let's the second team member put in their key and so on.
a scary amount of users are using the same rather weak password for lots of different accounts
This is true, but you can force them to use a random password just as easily as you can force them to use a randomly generated key. The end UX can look basically identical if you want it to. My point is that this is basically a UX problem. Instead of just making the change we are inventing this new protocol to shuffle along a UX change at the same time. Maybe part of this is because the change has major unaddressed downsides that would be too obvious to slip by if made as an incremental upgrade to passwords.
One team person does the login, adds a key, then let’s the second team member put in their key and so on.
There is no reason you can't have multiple passwords associated with an account.
Not sure if this applies but incidentally I changed my otp manager from microsoft to vaultwarden today. Adding security keys in the process is mostly two additional clicks. Of the 20 accounts I migrated, only about 7 had the option and only with one it was more work than adding totp.
Its a pretty tough decision what to use for this imo since technically, you‘re right. Then again, you already have to log into your os and unlock the password safe to get the passwords or the otps.
The reason why mfa is done is if your password leaks you are not completely effed. You can obviously use a second selfhosted service with a different password but chances are most people would rather use something easier.
Also, passkeys work the same way. They work if you are logged into a device. That way you get no additional password except you can only use it from the device in question.