Very solid points, and I love the focus on the fact that passkeys are addressing threats irrelevant to regular people, while ignoring those that matter. But I think it's still incomplete, because it's missing the biggest blind spot in design:
Password sharing is a feature, not a bug.
Security industry failed to implement the most basic feature one does with access control at individual level, which is delegation of authority. Physical security in form of "bearer" devices, such as keys, credit/debit cards, transit tickets (except those newfangled ones bound to photo ID), etc. all support this by default.
Ad-hoc delegation of authority is a normal thing to do, something we do all the time without thinking. Asking your kid or friend to do groceries for you? You hand them your debit card and give the PIN. Need a nanny to walk your kid from school and stay with them until you're back? You make them a copy of your house keys.
This carried over naturally to technology realm. A colleague needs to get some data that happens to exist only on your machine, while you're away? In normal non-corporate places, you just write the password on a post-it and give it to them, or put it in a drawer and tell them to go look there.
Security industry failed to provide a reasonable alternative path for over four decades now, and instead continues to deny the very existence of the need for ad-hoc delegation of authority. Passkeys are a bad choice for regular users largely because they're designed to prevent delegation - on top of the other issue, that the author correctly recognized, which is that by far the biggest threat to regular user is that of loss of access to account.
On a system I'm designing, you can provide a 2nd (or 3rd, 4th) password, which affords an user of said username/password combination a subset of the permissions _you_ have, which stops working after a date.
This has made multiple product owners cry. I am wondering if it would make sense to add a 2ndary action prompting the user at the eol for this secondary credential asking them if it went fine, to try and collect some information on how popular the feature is.
Oh cool. Would you mind expanding a bit on the implementation? I have been thinking about a generic auth system like this for some time.
That's nice and I applaud you for attempting to solve it in a user-friendly way.
Sadly, because that'll come off as unusual to 99%+ of your userbase, you'll probably face challenges explaining this to the users, and it'll skew statistics you gather here. Chicken and egg problem, really :(.
All true, but there's a wrinkle with delegating auth in computer systems--the same wrinkle that comes up when thinking about digital data as property/copyrightable etc.: when you delegate auth, you copy the access; you don't loan it. So every digital delegated-auth scenario is like your "make a copy of your house keys" example, not your "loan out your debit card" example.
If we extend the metaphor, this would be like making a copy of your keys and handing those out every time someone other than you needed access to your house. Dinner guest? Key copy. Neighbor dropping off a borrowed tool? Key copy. Relative from out of town visiting? Key copy.
In the same way that I think most homeowners would look askance at passing out so many copies of their keys, delegated digital auth is troublesome. Nontechnical users are unlikely to pay attention to "what clients are using delegated credentials for which actions" dashboards. Revocation, while technically easy, isn't something that I think most casual users will be mindful of, resulting in endless growth in the list of principals with access to a resource (just like the "sharing passwords" scenario we have now). Time-based auto-revocation will be an annoyance for delegates who only need to access a resource rarely, resulting in exasperated administrators rubber-stamping new-delegate-credentials requests.
I don't know if there's a good solve here. Shared passwords might be the local maximum of convenience and security, but that feels pretty bad.
>passkeys are addressing threats irrelevant to regular people
phishing is very relevant to regular people
Not really that much in comparison to losing access when needed. It's relevant to corporate employees, where phishing is worthwhile to attackers, while losing access means creating a ticket on internal helpdesk and having rest of the day off.
corporate employees are typically regular people, and where phishing resistance is most valuable.
if by regular people, you meant "in someone's personal life", i would say phishing resistance is still relevant but agree that loss of access becomes a bigger risk to balance
> if by regular people, you meant "in someone's personal life"
Right, this is what I meant. I used "regular people" as shorthand for that, which I see wasn't a good choice. Next time around I'll be more clear.
Don’t you remember the giant phishing campaigns like back when lots of celebrities got their nudes in iCloud stolen and published? These things happen all the time, and are incredibly painful. Much, much more so than being unable to share your account with a coworker.
> ...when lots of celebrities got their nudes in iCloud stolen and published?
Right-- high-value victims of targeted attacks. So not regular people.
Regular people get their data stolen all the time, you just don’t hear about it. Just look at the credential dumps and the most common passwords.
I don't get the sense that regular people get data "stolen".
Ransom is the only thing I see happening to end user data.
Credential thefts facilitate theft of money. It might might help the attacker to rifle thru somebody's data to find information that helps answer "secret" questions, to trick friend and family into getting phished, and maybe blackmail, but I don't see a market for end user data that would drive data theft. Nobody is buying end user photos, videos, email, etc. (Anybody who would possibly buy it just tricks/entices users into giving it to them for free to train their AI models anyway.)
LLMs ironically are changing this[0], but at least until now, rifling through random people's data did not scale, so aside for a subset of cases where it was possible to automate access to some services or otherwise leverage them into a scam on the cheap, it wasn't of interest because there was literally nothing useful to do with it.
--
[0] - LLMs, whether multimodal or combined with modern AI-driven STT / TTS pipeline, enable running highly personalized scams cheaply and in an automated fashion, which does scale up and suddenly makes this data important. But that's a very new consideration, one which passkeys were not designed for, because it literally was not possible or conceivable even few years ago.
At the scale you'd expect that to happen, looking at credential dumps, you'd also expect to hear a lot about it.
And yet, you don't. Which leads me to the conclusion that the data dump are overblown.
I think companies around the world come to the same obvious conclusion, which is why these data breaches keep happening, and the companies whose systems were breached are never any worse for the wear.
You can add multiple passkeys in the vast majority of websites that support them. There's nothing in the spec that prevents or discourages allowing multiple credentials. I do it on every site I care about so I can fallback to the OS passkey store if I lost access to my Bitwarden account for whatever reason.
Much like with 2FA apps, most of the sites I've seen - including big names - support only one app and one passkey at a time.