4 ms·
Passkeys are in their infancy. You don't go about rolling out such patterns when most users haven't even switched yet and big players like Apple are still resis
by t_mann 1y ago
Passkeys are in their infancy. You don't go about rolling out such patterns when most users haven't even switched yet and big players like Apple are still resisting attestations (last time I checked). The problem is that the feature is there and can be (ab)-used in this way, so it should be rejected on principle, irrespective of whether it's a problem right now.
I understand the value of attestations in a corporate environment when you want to lock down your employees' devices. But that could simply have been handled through a separate standard for that use case.
- drdaeman 1y agoAt the very least the spec should be painstakingly insistent on not requiring attestation unless implementors have really thought and understood the reasons why they need the security properties provided by attestation in their particular use case. And that it has to be something more meaningful than “be more secure this way” as security is not a rating (even though security ratings exist) but a set of properties, and not every possible security guarantee is universally desirable (please correct me if I’m wrong here, of course), and at least some are not without downsides. Maybe even strongly recommend library authors to pass the message on.
- t_mann 1y agoI agree, but unfortunately the spec authors are already going out and dangling possible bans in front of projects who implement Passkeys in more user-friendly ways: https://github.com/keepassxreboot/keepassxc/issues/10407 https://github.com/keepassxreboot/keepassxc/issues/10407 > To be very honest here, you risk having KeePassXC blocked by relying parties But having a choice about how you store your credentials shouldn't depend on the good faith of service providers or the spec authors who are doing their bidding anyway. It's a bit similar to sideloading apps, and it should probably be treated similarly (ie, make it a right for users).
- growse 1y agoThere'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.
- account42 1y agoWhat people do on their own computer is none of the service's business.
- growse 1y agoIt is if it puts the service at risk.
- AlexandrB 1y agoThis 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 1y agoDo 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.
- eredengrin 1y agoSure, 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.
- sam_lowry_ 1y agoThe exact point of passkeys is to remove all rights from users )
- charcircuit 1y agoEnsuring 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 1y agoYou don't need attestation to allow users to secure their passwords.
- charcircuit 1y agoYou don't, but with one services have a better guarantee that they are.
- sam_lowry_ 1y agoServices, by definition, serve. Why should we, the users, care about their guarantees?
- charcircuit 1y agoBecause 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_ 1y agoI 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 1y agoReducing 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.
- zekica 1y agoHow 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 1y agoI'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.
- kbolino 1y agoPasskeys 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 1y agoWith password managers passwords are not reused which avoids this problem already.
- kbolino 1y agoNot 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.
- rezonant 1y agoApple hasn't been particularly resistant to offering device attestation. The DeviceCheck / App Attest system has been offered since iOS 11 released in 2017. https://developer.apple.com/documentation/devicecheck https://developer.apple.com/documentation/devicecheck
- argsnd 1y agoI assume they mean attention in the webauthn/passkey specs specifically