26 ms·

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 t

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.

john_strinlai 23d ago
>passkeys are addressing threats irrelevant to regular people phishing is very relevant to regular people
- TeMPOraL 23d ago
  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.
  - john_strinlai 23d ago
    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
    - TeMPOraL 23d ago
      > 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.
  - 9dev 23d ago
    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.
    - EvanAnderson 23d ago
      > ...when lots of celebrities got their nudes in iCloud stolen and published? Right-- high-value victims of targeted attacks. So not regular people.
      - 9dev 23d ago
        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.
        TeMPOraL 23d 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.
fortyninenine 23d ago
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.
- TeMPOraL 23d ago
  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 :(.
- raphman 22d ago
  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.
qlte 22d ago
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.
- TeMPOraL 22d ago
  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.
zbentley 22d ago
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.

john_strinlai 23d ago

>passkeys are addressing threats irrelevant to regular people phishing is very relevant to regular people

TeMPOraL 23d ago
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.
- john_strinlai 23d ago
  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
  - TeMPOraL 23d ago
    > 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.
- 9dev 23d ago
  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.
  - EvanAnderson 23d ago
    > ...when lots of celebrities got their nudes in iCloud stolen and published? Right-- high-value victims of targeted attacks. So not regular people.
    - 9dev 23d ago
      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.
      - TeMPOraL 23d 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.

fortyninenine 23d ago

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.

TeMPOraL 23d ago
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 :(.
raphman 22d ago
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.

qlte 22d ago

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.

TeMPOraL 22d ago
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.

zbentley 22d ago

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.