Source: www.schneier.com – Author: Bruce Schneier
Comments
Matt •
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.
Gary •
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 •
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 •
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 •
@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 •
“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 •
“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 •
@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 •
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 •
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 •
@ 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 •
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 •
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.
Nick Alcock •
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 •
@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 •
@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.
Subscribe to comments on this entry
Sidebar photo of Bruce Schneier by Joe MacInnis.
Original Post URL: https://www.schneier.com/blog/archives/2024/02/on-passkey-usability.html
Category & Tags: Uncategorized,passwords,usability – Uncategorized,passwords,usability
