| |
| ▲ | growse 9 days ago | parent | next [-] | | There's a tension here between "user freedom" and a service wanting to make sure that credentials that it trusts to grant access to stuff aren't just being yolo'd around into textfiles on people's dropboxes. People forget that one of the purposes of authentication is to protect both the end user and the service operator. | | |
| ▲ | eredengrin 9 days ago | parent | next [-] | | Sure, but as long as the fallback for account recovery is sending a reset email or sms (both of which are similar or worse than yoloing textfiles on dropboxes), that's a very tough argument to make in good faith. | | |
| ▲ | growse 9 days ago | parent [-] | | I agree that account recovery isn't the best. But just because that sucks doesn't mean there's zero value in improving credentials. |
| |
| ▲ | account42 9 days ago | parent | prev | next [-] | | What people do on their own computer is none of the service's business. | | |
| ▲ | growse 9 days ago | parent [-] | | It is if it puts the service at risk. | | |
| ▲ | AlexandrB 9 days ago | parent [-] | | This attitude has got to stop. Is it not enough that there's no customer service and it's almost impossible to sue these companies thanks to arbitration clauses? Now they need to have control over our computing to keep themselves safe? And how many recorded incidents of losing an account because someone had their "password in a text file" are even out there? The most common scenarios one hears about are either phishing or social engineering. | | |
| ▲ | growse 9 days ago | parent [-] | | Do you think someone running a service that's under constant denial-of-service attacks would be sympathetic to the argument that "What people do on their own computer is none of the service's business". Pretty much every service out there has "don't share credentials" in their ToU. You don't have to like it, but you also don't have to accept the ToU. |
|
|
| |
| ▲ | nyeah 9 days ago | parent | prev | next [-] | | Note the scare quotes around user freedom. Perhaps user freedom is a notorious fake issue, a bizarre misconception, or an exotic concept that nobody understands. | | |
| ▲ | growse 9 days ago | parent [-] | | I don't know what "scare quotes" are. They're just regular quotation marks, because I'm quoting. | | |
| ▲ | nyeah 9 days ago | parent [-] | | Sure, I stand corrected, you "don't know" what I'm talking about. | | |
| ▲ | growse 9 days ago | parent [-] | | Literally no idea. My point was that freedom is not an absolute, it's balanced against other freedoms. It's hard to tell whether you agree with that or not. |
|
|
| |
| ▲ | tsimionescu 9 days ago | parent | prev [-] | | What does Microsoft stand to lose if someone steals my passkey for Outlook from a text file I yolo'd into a Dropbox? |
| |
| ▲ | sam_lowry_ 9 days ago | parent | prev | next [-] | | The exact point of passkeys is to remove all rights from users ) | | |
| ▲ | charcircuit 9 days ago | parent [-] | | Ensuring it's not possible for remote attackers to easily steal users passkeys is not "removing all rights" for someone. It is setting a security bar you have to pass. One user's poor security can have negative effects on not just them but the platform itself. | | |
| ▲ | account42 9 days ago | parent [-] | | You don't need attestation to allow users to secure their passwords. | | |
| ▲ | charcircuit 9 days ago | parent [-] | | You don't, but with one services have a better guarantee that they are. | | |
| ▲ | drdaeman 9 days ago | parent | next [-] | | You’re falling for the exact “better security” fallacy I was trying to warn about. Security is not a rating, “better security/guarantee” is not a really meaningful phrase on its own, even though it’s very tempting to take mental shortcuts and think in such terms. Attestation provides a guarantee that the credential is stored in a system controlled by a specific vendor. It’s not “more” or “less” secure, it’s just what it literally says. It provides guarantees of uniformity, not safe storage of credentials. An implementation from a different vendor is not necessarily flawed! And properties/guarantees don’t live on some universal (or majority-applicable) “good-to-bad” scale, no such thing exists. This could make sense in a corporate setting, where corporate may have a meaningful reason to want predictability and uniformity. It doesn’t make sense in a free-for-all open world scenario where visitors are diverse. I guess it’s the same nearsighted attitude that makes companies think they want to stifle competition, even though history has plenty of examples how it leads to net negative effects in the long run despite all the short term benefits. It’s as if ‘00s browser wars haven’t taught people anything (IE won back then - and where is it now?) | | |
| ▲ | charcircuit 9 days ago | parent [-] | | >You’re falling for the exact “better security” fallacy How is it a fallacy? The rate of account compromises is a real metric that is affected by how good security there is for accounts. | | |
| ▲ | drdaeman 9 days ago | parent | next [-] | | I've tried to explain it in my comment above. Yes, the rate of account compromises is a metric we can define. But attestation doesn't directly or invariably improve this metric. It may do so in some specific scenarios, but it's not universally true (unless proven otherwise, which I highly doubt). In other words, it's not an immediate consequence. It could help to try to imagine a scenario where limited choice can actually degrade this metric. For example, bugs happen - remember that Infineon vulnerability affecting Yubikeys, or Debian predictable RNG issue, or many more implementation flaws, or various master key leaks. The less diverse the landscape is, the worse the ripples are. And that's just what I can think of right away. (Once again, attestation does not guarantee that implementation is secure, only that it was signed by keys that are supposed to be only in possession of a specific vendor.) Also, this is not the only metric that may possibly matter. If we think of it, we probably don't want to tunnel vision ourselves into oversimplifying the system, heading into the infamous "lies, damned lies, and statistics" territory. It is dangerous to do so when the true scope is huge - and we're talking about Internet-wide standard so it's mindbogglingly so. All the side effects cannot be neglected, not even in a name of some arbitrarily-selected "greater good". All this said, please be aware that I'm not saying that lack of attestation is not without possible negative effects. Not at all, I can imagine things working either way in different scenarios. All I'm saying that it's not simple or straightforward, and that careful consideration must be taken. As with everything in our lives, I guess. | |
| ▲ | GoblinSlayer 7 days ago | parent | prev [-] | | It's just passwords from HIBP, you're not going to solve any other attack. |
|
| |
| ▲ | sam_lowry_ 9 days ago | parent | prev [-] | | Services, by definition, serve. Why should we, the users, care about their guarantees? | | |
| ▲ | charcircuit 9 days ago | parent [-] | | Because users want the services they use to be good. They don't want to be sent phishing links from their friend's account that was hijacked by attackers. | | |
| ▲ | sam_lowry_ 9 days ago | parent [-] | | I had a meeting with a public servant this morning. He is part of an organization that promotes multi-factor authentication and publicly endorses the view that users are stupid. The meeting was about him unable to test the APK of the new version of their mobile app. He felt embarrassed, his mobile phone is enrolled in the MDM scheme that disallows side-loading of apps. What I am trying to say is that assuming users are stupid carries a non-negligible risk that you will be that stupid user one day. | | |
| ▲ | charcircuit 9 days ago | parent [-] | | The solution here sounds like having a separate development device that is used to sideload test versions of the app. The idea is that devices may require different levels of security depending on how much can be accessed from that device. |
|
|
|
|
|
|
| |
| ▲ | charcircuit 9 days ago | parent | prev [-] | | Reducing passkeys to the security level of passwords is not just "making something user friendly". It's undoing all of the hardware everyone else in the ecosystem is putting into to making a more secure way for authentication to be done. | | |
| ▲ | kbolino 9 days ago | parent | next [-] | | Passkeys have several advantages over passwords but not all of them rely on UX controls. They are, after all, public-private keypairs and the private part is never shared during authentication. The wider web never adopted PAKEs so passwords are still sent verbatim over the (TLS-protected) wire. | | |
| ▲ | charcircuit 9 days ago | parent [-] | | With password managers passwords are not reused which avoids this problem already. | | |
| ▲ | kbolino 9 days ago | parent [-] | | Not reusing passwords across sites greatly limits the blast radius but verbatim password exchange still carries its own risks. The widespread adoption of TLS addressed most of the issues, as I alluded to already, but there are still insider threats, MITM phishers, and infrastructure compromises from time to time. |
|
| |
| ▲ | zekica 9 days ago | parent | prev [-] | | How exactly is this "reducing the security level to those of passwords"? For example: you can't use a passkey on attacker's web site even if you have a plaintext copy of the private key. | | |
| ▲ | charcircuit 9 days ago | parent [-] | | I'm not following. The issue is about it being used for the site the private key is for. The attacker's site is irrelevant here. |
|
|
|
