On Passkey Usability
Matt Burgess tries to only use passkeys. The results are mixed.
Comments
Gary • February 12, 2024 2:19 PM
Unfortunately the current implementations of passkeys don’t scale beyond a few instances per user because of keychain sync & lack any in-system breach recovery.
Kevin • February 12, 2024 2:31 PM
Don’t let the perfect be the enemy of the good. Account recovery is a big problem with passkeys, but it’s just as big a problem with passwords. If account recovery is your biggest passkey issue, well, we’re doing pretty well.
Passkeys make me (and I suspect many technical folks) nervous because they move the security out of our direct control and into the control of an opaque program (phone, browser, OS, whatever). Just like folks feel safer driving a car rather than riding on an airplane, even though the most dangerous part of the whole journey is the drive to/from the airport. Looking at it clearly, Chrome probably does a better job securing secrets than my brain does (and I’m a very careful person who has worked in computer security).
My main issues with passkeys involve me moving to new devices on new OSs with new browsers; I want all of my secrets to migrate, and we don’t have any good ways to handle that. A password manager and some transfers and swearing is how I handle this for passwords.
paulT • February 12, 2024 2:33 PM
I still prefer passwords with a good password manager. I have strength per website, combined with an easier time recovering everything than if I lose my phone.
I know passkeys are still more secure, but ease of use for recovery just isn’t there yet.
Matt • February 12, 2024 3:05 PM
@kevin “If account recovery is your biggest passkey issue, well, we’re doing pretty well.”
I agree we’re doing better than before (don’t get me wrong, I fully approve of Webauthn/passkeys/etc. as a replacement for passwords), but account recovery is still a common enough thing that I think it’s worth worrying about, and it’s something I rarely see discussion about.
When it is discussed, I see a lot of “use a cloud passkeys provider” (e.g. Google); then the “account recovery” problem is winnowed down to a single account (e.g. your Google account). But then all your eggs are in one basket: If someone else can recover your Google account, bam, now they’ve got access to and control of everything. Fundamentally it’s the same issue as having your “account recovery” method be via email or SMS, where access to a single thing (e.g. an email inbox) gives control over everything that relies on that thing.
I know there’s always a balance between convenience and security. One answer to the problem is, indeed, to simply accept having to write down and store recovery codes for all of one’s accounts. Tedious, but relatively simple (you could write them in a paper notebook to avoid any risk of the codes being stolen via hacking; or store them in an encrypted file on your hard drive that only you know the key to decrypt; etc.). (Something like this is in fact what I do, because while I could store my passkeys with Google, I’m trying to minimize my reliance on their security, as well as avoid the single-point-of-failure problem.) But I know that that’s not something the average user is going to bother with.
Chris Smith • February 12, 2024 3:13 PM
“One is stored by the website or app; the other is saved on your device.”
And there is the one big catch – not everyone will have a device.
There is an end of the scale where the homeless use library computers. They typically do not have “a device”, and are often challenged to pay for it, or protect it, or both.
As capable as passkeys might be, they appear to place an economic barrier in the way of improved security for some people.
So, as much as ‘use a passkey’ might start to be a default, in many cases it cannot become the only authentication method. Unless there is a development of a ‘device-less passkey system’, passwords are going to be around for a really long time.
emily’s post • February 12, 2024 3:19 PM
“Put all your eggs in the one basket and – WATCH THAT BASKET”
Added in 2nd edition: keep a spare backup copy of dehydrated eggs.
Sofa • February 12, 2024 5:30 PM
@Matt wrote:
There’s one advantage over the traditional password ecosystem: recovery codes are always long and randomly generated (and so effectively cannot be weak or reused across sites)
I am not sure what you are using, but the recovery codes I have seen are usually all part of a schema with, for example, some combination of five letters or numbers, a hyphen, and some combination of five letters or numbers. They aren’t necessarily even using uppercase letters. I believe that reduces the keyspace required to check while simultaneously increasing the probability of a successful brute force attack.
Roger Schlafly • February 12, 2024 6:40 PM
Google and Microsoft sure do not explain what they are doing with passkeys. Do they replace passwords? Are they backed up? What if access to the passkeys is lost? Can they be transferred? How are they protected? Can you disavow a passkey if it is compromised? Passkeys can be saved to an external security key, but how does that work? Can I see what passkeys are on the security key?
bjkeefe • February 12, 2024 6:56 PM
Reply to @Sofa: I take your concern, but I do wonder how realistic it is, in that I don’t know how one would brute force login attempts in the context of account recovery. Presumably, any site sophisticated enough to support passkeys and recovery codes it not going to allow more than a few attempts at logging in with a recovery code. So, how, in practice, do you see this being a realistic threat?
Granted, if the attacker gained access to a file of recovery codes, it’s conceivable that they could be decrypted offline. But this seems like a pretty remote possibility, too.
Clive Robinson • February 12, 2024 8:18 PM
@ bjkeefe, sofa, ALL,
Re : Security fails on presumption and assumption.
“Presumably, any site sophisticated enough to support passkeys and recovery codes it not going to allow more than a few attempts at logging in with a recovery code.”
Actually as a general rule on non internal only sites that is nolonger a valid presumption with ordinary passwords.
That is the prefered method as it vastly reduces support costs is,
1, Rate limit.
2, Send new shared secret to an email address in plaintext.
Simple logic indicates,
A, The security is low.
B, Security becomes weaker with time.
C, Security becomes weaker with the attackers increasing resources.
However the mentality behind this view point will “carry forward” into all future authentication systems irrespective of what they are unless the system builds it out. But any system that does build it out by definition incresses support costs, so won’t get used where it can be avoided (it’s actually seem as a legal requirment towards shareholder value…).
Spencer • February 13, 2024 2:01 AM
I use a password manager and am careful too use long randomly generated passwords and not reuse them. I unlock my password manager with a fingerprint, and on trusted devices it also fills TOTP.
Is there any security or usability benefit to a passkey for me? It seems like the main motivation is blocking users who have bad personal password practices.
Brutus • February 13, 2024 3:27 AM
The way Big Tech implement passkeys, it is entirely predictable that passkeys is going to be a mess. In fact, someone already anticipated that a couple of years ago: Why will passkeys end up in a mess for most people?.
I prefer Steve Gibson’s SQRL. It is superior to passkeys. Steve Gibson completely thought through the issues and covered all bases, both from the technical and end-user standpoint. Steve Gibson had generously released SQRL as a free and open standard and he didn’t even patent it.
But unfortunately, we are all stuck with passkey as the second best solution. The average end user is going to end up with a mess with passkeys. It’ll be a shame because that will discourage end-user adoption and the world will remain stuck in password hell.
Not really anonymous • February 13, 2024 3:59 AM
William Brown gave a talk about Passkeys at Everything Open (a follow on to Linux Conf AU) in 2023. A recording is archived at https://mirror.linux.org.au/pub/everythingopen/2023/clarendon_room_d/Wednesday/Webauthn_Passkeys_and_You_The_Future_of_Authentication.webm . You can also find it on youtube.
The biggest takeaway I got from the talk, was that the big advantage of passkeys is that they are tied to a domain name in a way that they won’t be provided to lookalike sites. This blocks a common type of attack.
The talk also covers some limitations of passkeys.
Nick Alcock • February 13, 2024 10:20 AM
Everyone above talking about recovery keys is haring up the wrong tree. You should never ever need them, any more than you need one for your front door. Instead, you have multiple keys, keep them in different places, and enroll them all with everything.
(This replaces one problem with another one — if you keep them in different places, how do you remember to enroll the one you keep in a different place with all the services into which you enrolled the one you have with you? Myself, I treat them like backups, with three keys, one offsite, and keep three sorted lists of the services I’ve enrolled each key into so far. When I swap out the backup, I use the key I had on me all along to log in to all the services the backup isn’t enrolled in and enroll it, and add them to the list for that key: then the next one I swap out offsite is the one I didn’t re-enroll this time. Is this more annoying and harder-to-manage than passwords? Yes, probably 🙁 )
My worry with passkeys is that they’re saying oh you don’t need usernames any more or anything else! but this is assuming that passkeys are protected by fingerprint readers or something, i.e. that they are all phones. If you’re using a Yubikey or something as a passkey, if someone steals it and uses it before you find out and revoke it everywhere, they can log in as you without even knowing your username, just stick the key in and whoops! I’d much rather passkeys had stayed like U2F, as a second or third factor. Remembering usernames isn’t that hard, and it probably does keep us safer from pickpockets.
Matt • February 13, 2024 11:16 AM
@Nick Alcock “My worry with passkeys is that they’re saying oh you don’t need usernames any more or anything else!”
Not really, no, mainly because it’s a really big and obvious security weakness to have a single piece of data provide not only identification but also authentication, so RPs aren’t likely to implement that.
On a technical level, roaming authenticators (eg Yubikeys) have very limited storage; storing the login info and keys for 100+ websites is simply not an option. Most of the time they don’t store keys at all; during the registration process, they generate a random number and a private key, and then use the device’s master private key to encrypt the new private key using the random number. Then they concatenate the random number and the private key and send that as the key ID to the RP, along with the public key. This then tricks the RP into storing the private key (since the RP treats the key ID as an opaque value). Later, during authentication, the RP sends the key ID to the authenticator, from which the authenticator can extract the private key in order to complete the challenge.
kurker • February 13, 2024 12:37 PM
@Matt
re eliminating usernames: “RPs aren’t likely to implement that.”
But they do already, or at least seem to. Both my phone and laptop are now “trusted devices”, which is yet another reason to worry about their physical security. Then what about those people mentioned by others above, who don’t own a device to be trusted, but use public terminals? You might be happy to use facial ID to authenticate, but faces can vary with emotion and health. I can’t use fingerprints because they wear or get damaged by my work. Passkeys are indeed a solution, but the problem is ill-defined, so there may be other better solutions.
Ralph Haygood • February 14, 2024 1:57 AM
As someone who makes web applications for a living, I’m not implementing passkeys for the time being. Briefly, the problem is that, as the Wired piece indicates, the experience of using them is unfamiliar to most people and often poor on older devices. If Apple, Google, Microsoft, etc. ever persuade sizable proportions of their users to use passkeys, I’ll reconsider, but until then, I’m not interested in pioneering that user experience, which I suspect would entail quite a lot of user support.
Moz in Oz • February 14, 2024 3:10 AM
One issue with letting Google or similar control everything is that when you get locked out of your google account you need to be famous to get back in. Even AI-based support can’t help most people. They have to just write it off and create a new one.
The other famous “recovery” option is to let people choose to log in with a user/pass combo, optionally with SMS/email “2FA”. I understand than Vanguard still do this.
“trusted devices” are great, until they’re not. If I break or lose my phone, or the app requirements change so my phone is no longer good enough, my.gov.au require me to go to a government service desk and physically re-identify myself so I can enrol a new device. You can only have one device set up as your authenticator, but as long as it is still usable you can un-enroll it and set up a new one (so the help says).
That’s kind of ok for one organisation, that has many physical help desks. But for the other 30+ accounts it would range from annoying (the bank I use is based two hours away and has exactly one physical branch), but my paypal account? I don’t think they have physical support desks anywhere in the world. It’s strictly “have your device or know someone who works at paypal”.
lurker • February 14, 2024 4:32 PM
@Moz in Oz
Funny you should mention PayPal, because they appear to offer the login choice of username/password, except, it doesn’t work for me. No, not forgotten password, clicking the button for that choice does nothing.
Martin • February 15, 2024 9:42 AM
@Matt
The problem with passkeys + Yubikeys is that as per the standard, passkeys are residential credentials.
Stupid choice IMHO. Without that requirement, or if that would at least be optional in the standard, non-discoverable credentials could be used as the passkey, which would really give you an unlimited amount of passkeys you could enroll to with a single Yubikey.
Nick Alcock • February 16, 2024 9:56 AM
@Martin, yes, that’s the term I was missing: they’re resident. I wonder if there’s a way to disable the use of resident credentials entirely? I can’t see any situation in which I’d ever want to use them. I can remember usernames 🙂
Paul Sagi • February 20, 2024 11:16 PM
I’ve wondered about the time and effort tech companies put into Passkeys and Blockchain DNS.
I wonder because private companies are looking for ROI.
IMHO there must be cost savings in terms of tech company infrastructure OR the tech companies are pressured by government(s) to weaken online privacy.
Paul Sagi
Paul Sagi • February 20, 2024 11:29 PM
Passkey encryption is based on prime numbers, which is an outdated and weak method of encryption.
I’ve not seen anywhere mention of precisely what cipher is used and it’s key length. That’s suspicious, it’s obfuscation. It’s thus not possible to know how strong the encryption actually is, but as I noted, it’s not very strong, because of being based on prime numbers.
To use the passkey, the ‘device’ uses a biometric or PIN, both of which have been found to be fairly easy to defeat.
So I asked myself why the hoopla about passkeys? They are too weak to be better protection than passwords and MFA, so why are tech companies promoting passkeys?
Could it be that government intell agencies are wanting people to use weak account protection, to make surveillance easier, including making it possible for tech companies to do surveillance that would then be handed over to governments?
Another motive for tech companies to do surveillance is to collect more personal data to sell to advertisers, insurance companies, governments, anyone willing to pay the asked price.
What that indicates to me is that passkeys are to be actively avoided.
Google is well known to conduct collection of personal data, as is Facebook (now Meta).
https://contrachrome.com/ContraChrome_en.pdf
Another hoopla has been about blockchains, supposedly they permit secure and untraceable exchange of data. They are distributed (there are many copies, no one person can destroy all of them) and that makes transactions verifiable. In reality, researchers have found that the permanent record of a blockchain is traceable and people using blockchain technology are not actually anonymous, as had been publicly believed.
The latest AFAIK bad blockchain idea is Blockchain DNS. That’s going to (if adopted) make a permanent traceable record of every web page request of everyone, thus ending online privacy.
Again, it suits personal data collection by tech companies and government intell agencies.
Bottom line is: avoid Blockchain DNS and Passkeys, they are cyber minefields.
Paul Sagi
Paul Sagi • February 20, 2024 11:46 PM
Steve Gibson, a computer security guru of grc.com has developed an alternative to Passkeys:
Matt • February 26, 2024 3:47 PM
@Martin
The problem with passkeys + Yubikeys is that as per the standard, passkeys are residential credentials.
Stupid choice IMHO. Without that requirement, or if that would at least be optional in the standard, non-discoverable credentials could be used as the passkey, which would really give you an unlimited amount of passkeys you could enroll to with a single Yubikey.
As far as I know, this is not true. My Yubikey doesn’t store credentials at all; it regenerates the private key each time by using the key ID. Long story short:
- During registration, it generates a random key ID, and then uses the ID plus its internal master private key to generate a new key pair. It gives the public key and key ID to the RP, plus the challenge it signed with the new private key. It then discards the key pair.
- During authentication, the RP provides the key ID back to the Yubikey. It uses that key ID and its private master key to regenerate the same key pair, and it can now use the private key of that key pair to respond to the challenge.
It’s my understanding that resident keys are generally discouraged for the twin reasons of 1) limited storage space, and 2) lack of revocability.
Matt • February 26, 2024 3:51 PM
@Paul Sagi
Passkey encryption is based on prime numbers, which is an outdated and weak method of encryption.
[citation needed]
@Paul Sagi
Passkey encryption is based on prime numbers, which is an outdated and weak method of encryption.I’ve not seen anywhere mention of precisely what cipher is used and it’s key length. That’s suspicious, it’s obfuscation. It’s thus not possible to know how strong the encryption actually is, but as I noted, it’s not very strong, because of being based on prime numbers.
Maybe you should try actually looking at the Webauthn spec, which goes into detail about which algorithms are used/supported. Mainly it’s elliptic curve stuff.
@Paul Sagi
To use the passkey, the ‘device’ uses a biometric or PIN, both of which have been found to be fairly easy to defeat.
“Fairly easy” if you are the NSA and in physical possession of the device. Still actually kinda difficult. Passkeys are intended to generally improve security across the board (mainly by eliminating phishing), not provide unbreakable security against nation-states.
The rest of your post is basically fearmongering.
Subscribe to comments on this entry
Leave a comment
Sidebar photo of Bruce Schneier by Joe MacInnis.
Matt • February 12, 2024 12:39 PM
Nice article, but no mention of account recovery in case you lose your passkey. What I’ve seen typically is the same “recovery codes” approach since MFA started being a thing. Those are effectively a bunch of single-use passwords, and managing the recovery codes for a bunch of websites isn’t much different of a problem (either for websites or for users!) as managing passwords.
What this in effect means is that while passkeys get rid of a lot of the hassle of day-to-day password use, the entire password infrastructure still exists on both sides: websites still have to store them, and so do users. There’s one advantage over the traditional password ecosystem: recovery codes are always long and randomly-generated (and so effectively cannot be weak or reused across sites). But they have a disadvantage, too, which is that because they are used so rarely, when you do need them, it may be even harder to find them—but you still need to maintain all of them for all the services you have accounts with because they’re the only way to get back in if you lose your passkeys.
I don’t know if anyone has worked on or devised a better system for account recovery that doesn’t require keeping big lists of recovery codes, or going through more rigorous authentication (e.g. calling your bank and giving them lots of personal info to prove that you’re you, so that you can reset your passkeys). But whenever I see articles about passkeys, they rarely seem to address this.