| ▲ | t_mann 9 days ago |
| The problems of Passkeys are more nuanced than just losing access when a device is lost (which actually doesn't need to happen depending on your setup). The biggest problem are attestations, which let services block users who use tools that give them more freedom. Passkeys, or more generally challenge-response protocols, could easily have been an amazing replacement for passwords and a win-win for everyone. Unfortunately, the reality of how they've been designed is that they will mainly serve to further cement the primacy of BigTech and take away user freedom. |
|
| ▲ | abustamam 9 days ago | parent | next [-] |
| I want to like passkeys but I haven't had any success getting them to work. Every time I click on "sign in using passkey" both my browser (Firefox or Chrome, on Android/Win/Mac) and Bitwarden are like "no passkeys found" and I'm never given an option to create one. I feel like I'm doing something stupidly wrong or missing a prompt somewhere, or maybe UX is just shitty everywhere, but if I, a millennial who grew up programming and building computers, struggle with this, then I don't expect my mom, who resets her password pretty much every time she needs to sign into her bank, to get it to work. |
| |
| ▲ | sbrother 9 days ago | parent | next [-] | | I'm in the same boat. I just cannot get them to work; they work sometimes on some browsers, but a solid majority of the time I click on "use passkey" I get a generic error message and end up going back and using the password flow. I haven't invested more time in this because if it's so unusable for me as an engineer, it's a non-starter for the general public. | | |
| ▲ | biinjo 6 days ago | parent [-] | | And then there is Sony Playstation network. Set a passkey on your account when you’re on a computer browsing their store or managing your account. Go to the playstation. Can’t login anymore. Passkey not supported. |
| |
| ▲ | MyNameIsFred 7 days ago | parent | prev | next [-] | | I'm a personal and professional advocate from r passkeys, yet I must acknowledge that your criticisms and skepticism are valid. I don't see this as a flaw in the passkeys concept so much as a growing pain. It's a very different mental model, and I've seen businesses make some very poor implementation decisions based on some poor understanding of what this system aims to be. That in turn adds to a bad consumer impression, a growing body of bad examples for others to look to and replucate, and it all just compounds. | |
| ▲ | qingcharles 9 days ago | parent | prev | next [-] | | I've found passkeys support on Windows to be a bit janky right now. You can get into weird scenarios where the passkeys don't work, but there's also no UI to remove them or reset them. This is especially annoying when you change out some component in your PC and it seems to void however they are encrypted and Windows can't figure out why it can't access them. It's too early for grandma to use, IMO. | |
| ▲ | maronato 2 days ago | parent | prev | next [-] | | Most websites don’t let users sign up with passkeys. You need to create an account using email/password and then go to their settings page and create a passkey. Now you can sign in with the passkey. | |
| ▲ | me-vs-cat 8 days ago | parent | prev | next [-] | | I use Bitwarden in Firefox and passkeys "just work" on Linux, Android, Mac, and Windows. Previously, I used the extension in Chrome (Linux, Android, Windows). The only relevant Bitwarden setting appears to be "Ask to save and use passkeys" under Notifications. I do turn off the browser's built-in password manager, though I believe anything else relevant I have at default. If you have those and they still aren't getting saved, then I'm at a loss, but wish I knew why they don't work for you. In Bitwarden, you can see if there's a passkey saved in an entry, as the creation timestamp is shown right under the password field and editing an entry also allows deleting a passkey. | |
| ▲ | FortuneSheer 8 days ago | parent | prev | next [-] | | Not just you. Browser support is horrid for physical passkeys, very hit and miss. Depends on the brand of the passkey i think. | |
| ▲ | palata 9 days ago | parent | prev [-] | | I've seen that kind of comments multiple times, and I don't get it. I use Yubikeys, and passkeys just work. On Chrome, Firefox and Safari, both on macOS and Linux (specifically Alpine). I also tried with iPhones (for my family), and it also just works. I haven't tried using an Android device, is it what you are trying? | | |
| ▲ | abustamam 8 days ago | parent [-] | | That might be the delta. I'm not using a hardware key (well, not a YubiKey). I'm using just my phone or browser. | | |
| ▲ | palata 7 days ago | parent [-] | | Could it be that your phone is not compatible with passkeys? E.g. many Android phones don't have a TPM, isn't that a requirement for passkeys on Android? As I said, it just works with iPhones and Yubikeys. | | |
| ▲ | abustamam 5 days ago | parent [-] | | Oddly, passkeys work on my phone on the Nintendo site, of all places. I can't seem to get it to work on Github. So it does work, just not everywhere. |
|
|
|
|
|
| ▲ | djrenren 9 days ago | parent | prev | next [-] |
| All non-enterprise big tech uses of passkeys (Google, Apple & Microsoft Accounts), do not require an attestation statement (or in spec-parlance, use the `None` or `Self` Attestation Types). The presence of other attestation types in the spec allows passkeys to replace the use of other classes of authentication that already exist (e.g. smartcard). For example, it's very reasonable for a company to want to ensure that all their employees are using hardware Yubikeys for authentication. Furthermore, sharing the bulk of implementation with the basic case is a huge win. Codepaths are better tested, the UIs are better supported on client computers, etc. The presence of attestations in the spec, does not impinge on user freedom in any meaningful way. |
|
| ▲ | tialaramex 9 days ago | parent | prev | next [-] |
| Do you have some examples where people actually require attestation in 3rd party facing systems? Or is this purely "But in theory..." and you've dismissed all the very real problems with the alternatives because you're scared of a theoretical problem ? I always reject attestation requests and I don't recall ever having been refused, so if this was a real problem it seems like I ought to have noticed by now. |
| |
| ▲ | tux3 9 days ago | parent | next [-] | | Microsoft Entra ID goes out of its way to enforce attestation for FIDO 2 keys. The protocol normally allows you to omit the attestation, but they worked around an extra call after a successful registration flow that sends you to an error page if your FIDO2 passkey isn't from one of these large approved vendors: https://learn.microsoft.com/en-us/entra/identity/authenticat... I found out by trying to prototype my own FIDO2 passkey, and losing my mind trying to understand why successful flow that worked fine on other websites failed with Microsoft. It turns out, you are not allowed to do that. | | |
| ▲ | frameset 9 days ago | parent | next [-] | | To defend Redmond here, Entra is an enterprise system. If the company you work for or are interfacing with wants to enforce attestation, that's their business. B2C I would expect more latitude on requiring attestation. | | |
| ▲ | Zak 9 days ago | parent | next [-] | | A problem is that once a thing like that exists, it ends up on security audit checklists and then people do it without knowing whether they have any reason to. | |
| ▲ | technion 9 days ago | parent | prev | next [-] | | I would counter argue being the person pushing passkeys in an enterprise: noone in the business knows what attestation is, but we're going to do it because the interface recommends it. | | |
| ▲ | jrockway 9 days ago | parent [-] | | I'm not sure it's the standards committee's fault that your employer hires people that don't know how to do their job. I think it's reasonable to have attestation for the corporate use case. If they're buying security devices from a certain vendor, it's reasonable for their server to check that the person pretending to be you at the other end is using one of those devices. It's an extra bit of confidence that you're actually you. | | |
| ▲ | ori_b 9 days ago | parent | next [-] | | It's the standards committees job to design standards that are difficult to misuse. | |
| ▲ | raxxorraxor 3 days ago | parent | prev [-] | | The most common fault of committees is that they overengineer processes and specs wander out of scope. The result is that users (dev & consumers) either neglect the bad parts or the spec doesn't get used at all. |
|
| |
| ▲ | clickety_clack 9 days ago | parent | prev | next [-] | | Exactly. For personal authentication, you are at least personally incentivized to do the right things. For corporate auth, people will do whatever it takes to skip any kind of login. I once knew a guy who refused to let his office computer go to sleep just to avoid having to enter his password to unlock his computer. He was a really senior guy too, so IT bent to allow him do this. What finally made him lock his computer was a colleague sending an email to all staff from his open outlook saying “Hi everyone, it’s my birthday today and I’m disappointed because hardly anyone has come by to wish me happy birthday”. The sheer mortification made him change his ways. | | |
| ▲ | projektfu 9 days ago | parent | next [-] | | A culture of harmlessly pranking computers left unlocked goes a long way. ThoughtWorks veterans know what I mean. | |
| ▲ | tonyhart7 9 days ago | parent | prev [-] | | lol this is funny, why he didn't want to sign in more often tho??? | | |
| ▲ | clickety_clack 9 days ago | parent | next [-] | | He was completely non technical and I guess he figured that IT should be able to work the security system around him. | |
| ▲ | adam_hn 9 days ago | parent | prev [-] | | The most common human trait ever.... laziness |
|
| |
| ▲ | eadmund 9 days ago | parent | prev [-] | | Don’t put in place systems which encourage lock-in, even at the B2B level. | | |
| ▲ | lmz 9 days ago | parent [-] | | Aren't those usually used inside an enterprise vs B2B between enterprises? |
|
| |
| ▲ | rcxdude 9 days ago | parent | prev | next [-] | | Ah, and even if you can turn it off as the administrator, you still need to include the attestation, it's just not checked. Gotta love Microsoft... | | |
| ▲ | wkat4242 9 days ago | parent [-] | | Yeah Microsoft is so annoying. It's also kicking me out every day now (with this passive aggressive "hang on while we're signing you out" message). On M365 business with Firefox on Linux with adblocker. I hate using their stuff so much. | | |
| ▲ | gmokki 8 days ago | parent [-] | | Same has been happening for for a few months. I get thrown out of all o365 services multiple times each day. | | |
| ▲ | wkat4242 8 days ago | parent [-] | | Yes me too since a couple months :( So annoying. It doesn't of course happen on Windows. It started with OneNote web a couple years ago. Every day that gave a popup "Your session needs to be refreshed) and it would reload all over again. Microsoft don't bother to make a OneNote desktop app for my platform and the web version is really terrible anyway (you can only search in one tab, not a whole notebook). So I moved to self-hosted Obsidian which I'm really happy with. Now I can basically see myself typing in a note from another client. But replacing Microsoft for email is another topic. |
|
|
| |
| ▲ | tialaramex 9 days ago | parent | prev [-] | | I don't work in August, so I can't (well, won't) check, but my boss had the infrastructure team turn on FIDO2 for the mandatory 2FA on our administrative accounts and I do not remember having any problems with this. I do remember explicitly telling them (because of course having agreed to do this they have no idea how and need our instructions) not to enable attestation because it's a bad idea, but you seem to be saying that it'll somehow be demanded (and then ignored) anyway and that was not my experience. So, I guess what I'm saying here is: Are you really sure it's demanded and then ignored if you turn it off from the administrative controls? Because that was not my impression. | | |
| ▲ | tux3 9 days ago | parent [-] | | It's been a little while, but I believe at the time you'd get a CTAP/CBOR MakeCredentialRequest, the browser would ask you to confirm that you allow MS to see the make and model of your security key, and it would send the response to a Microsoft VerifySecurityInfo API. If you refused to provide make and model, IIRC you would fail the check whether enforcement was enabled or not. Then if enforcement was enabled and your AAGUID didn't match the list, you would see a different error code. Either way, you're sending over an attestation. They understandably forbid attestation format "none" or self-signed attestations. It's possible that this has changed, but the doc page still seems to say they won't accept a device without a packed attestation, it's only that the AAGUID check can currently be skipped. |
|
| |
| ▲ | t_mann 9 days ago | parent | prev | next [-] | | 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 9 days ago | parent | next [-] | | At 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 9 days ago | parent [-] | | I 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 > 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 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. |
|
|
|
| |
| ▲ | rezonant 9 days ago | parent | prev [-] | | Apple 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 | | |
| ▲ | argsnd 9 days ago | parent [-] | | I assume they mean attention in the webauthn/passkey specs specifically |
|
| |
| ▲ | lelandbatey 9 days ago | parent | prev | next [-] | | The Fido2 folks really really want things to be so secure and centralized, with so little user freedom, and they want to use attestation to do it. Here's a Fido2 member (Okta) employee saying "If keepass allows users to back up passkeys to paper, I think we'll have to allow providers to block keepass via attestation." https://github.com/keepassxreboot/keepassxc/issues/10407#iss... All because passkeys backup is deemed "too unsafe and users should never be allowed that feature, so if you implement it we'll kick you out of the treehouse." The authoritarian nature of passkeys is already on full display. I hope they never get adopted and die. | | |
| ▲ | tad_tough_anne 9 days ago | parent | next [-] | | Those quotes aren't in your source. | |
| ▲ | timmyc123 9 days ago | parent | prev [-] | | Hi, since you mentioned me, that's not what was said and putting it in quotes as if I did is really inappropriate. I'll post the same response I replied to other on a different thread: Wild that you (and a few others) continue to make these accusations about me in these comments (and in other venues). 1) I've been one of the most vocal proponents of synced passkeys never being attested to ensure users can use the credential manager of their choice 2) What makes you think I have any say or control over the hundreds of millions of websites and services in the world? 3) There is no known synced passkey credential manager that attests passkeys. tl;dr attestation does not exist in the consumer synced passkey ecosystem. Period. | | |
| ▲ | jorams 9 days ago | parent | next [-] | | They paraphrased what you said in the thread, but I don't think it's much of a misrepresentation. You may have "been one of the most vocal proponents of synced passkeys never being attested to ensure users can use the credential manager of their choice", but as soon as one such credential manager allows export that becomes "something that I have previously rallied against but rethinking as of late because of these situations". There may not currently be attestation in the consumer synced passkey ecosystem, but
in the issue thread you say "you risk having KeePassXC blocked by relying parties". The fact that that possibility exists, and that the feature of allowing passkeys to be exported is enough to bring it up, is a huge problem. Especially if it's coming from "one of the most vocal proponents of synced passkeys never being attested", because that says a lot about whoever else is involved in protocol development. | | |
| ▲ | timmyc123 9 days ago | parent [-] | | You should really re-read the entire discussion. It wasn't about passkeys being able to be exported. It was specifically about clear text export. > The fact that that possibility exists, The possibility does not exist in the consumer synced passkey ecosystem. The post is from a year and a half ago. | | |
| ▲ | lelandbatey 8 days ago | parent [-] | | A year and a half ago doesn't really matter; that this was ever even a concern from the industry, something that the industry could make happen at all, or even just was thinking about doing at some point in the past, poisons the entire effort. In a world where password+totp already exists and requires almost no hoops, no dependencies and is incredibly secure vs basic password flows, it's no wonder that folks remember discussions around curtailing user freedom around a new authentication pattern which already was less convenient, offers less user control, and further centralizes infrastructure in the hands of a few major brokers of technological power. Until we have full E2E passkey implementations that are completely untethered from the major players, where you can do passkey auth with 3 raspberry pi's networked together and no broader internet connection, the security minded folks who have to adopt this stuff are going to remember when someone in the industry publicly said "if you don't use a YubiKey/iPhone/Android and connect to the internet, ~someone~ might ban you from using your authenticator of choice." | | |
| ▲ | timmyc123 8 days ago | parent [-] | | > Until we have full E2E passkey implementations that are completely untethered from the major players, where you can do passkey auth with 3 raspberry pi's networked together and no broader internet connection This is already possible today. And since it's a completely open ecosystem, you can even build your own credential manager if you choose! |
|
|
| |
| ▲ | 63stack 8 days ago | parent | prev [-] | | I don't believe it is a misrepresentation, you are bullying a project for letting users backup their own passkeys. >which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations). This is exactly why we need truly open standards, so people who believe they are acting for the greater good can't close their grubby hands over the ecosystem. |
|
| |
| ▲ | account42 9 days ago | parent | prev | next [-] | | Systems are usually more open while they are trying to onboard users than they will be once the moat has been established. We have already been through this with many services suddenly demanding that you give them your phone number "for security". | |
| ▲ | lmm 9 days ago | parent | prev | next [-] | | They're not going to start requiring them until they've phased out non-passkey login. But at that point it will be too late. | | |
| ▲ | XorNot 9 days ago | parent [-] | | I don't know why people don't see this coming: very obviously once Passkeys are everywhere, it'll become "we're requiring attestation from approved device bootloaders/enclaves" and that'll be your vendor lock in where it'll be just difficult enough that unless you stick with the same providers phone, you might lose all your passkeys. | | |
| ▲ | growse 9 days ago | parent | next [-] | | > very obviously once Passkeys are everywhere it'll become "we're requiring attestation from approved device bootloaders/enclaves" This is far from very obvious, especially given that Apple have gone out of their way to not provide attestation data for keychain passkeys. Any service requiring attestation for passkeys will effectively lock out every iPhone user - not going to happen. | | |
| ▲ | ori_b 9 days ago | parent [-] | | If there's no intention of doing this, it should be removed from the protocol. "I promise we'll never use this feature, so long as you implement it" isn't very convincing. | | |
| ▲ | growse 9 days ago | parent [-] | | Not all people who want to replace passwords are running services available to the general public. There are a bunch of service provider contexts where credential storage attestation is a really useful (and sometimes legally required!) feature. | | |
| ▲ | ori_b 9 days ago | parent [-] | | Great, they can use standards that aren't targeted at running services for the general public. It seems like the requirements already diverged. Drop attestation from passkeys, and I become a promoter. Keep it, and I suggest people stay away. If it's not something anyone intends to use on public services, this should be uncontroversial. Dropping attestation simplifies implementation, and makes adoption easier as a result. | | |
| ▲ | growse 9 days ago | parent [-] | | What makes you think that the Webauthn standards are "targeted at running services for the general public"? > It seems like the requirements already diverged. No, the requirements are _contextual_. This isn't a new idea. | | |
| ▲ | ori_b 9 days ago | parent [-] | | The fact that sites targeted at the general public are prompting me to use them. Should websites avoid using passkeys and webauthn? Would you like to tell them that they're doing it wrong? | | |
| ▲ | growse 9 days ago | parent [-] | | I missed a word out from my question. Let me try again. What makes you think that the Webauthn standards are _only_ "targeted at running services for the general public"? | | |
| ▲ | ori_b 9 days ago | parent [-] | | Yeah, so if you want me to trust them, the harmful parts need to get removed from specs used in public contexts. I would love to use public key cryptography to authenticate with websites, but enabling remote attestation is unacceptable. And pinky swears that attestation won't be used aren't good enough. I've seen enough promises broken. It needs to be systematic, by spec. Passwords suck. It's depressing that otherwise good alternatives carry poisonous baggage. If you make something possible, it will be used. | | |
| ▲ | growse 9 days ago | parent [-] | | > If you make something possible, it will be used. Sure, but that's not without tradeoffs. I come back to: > Any service requiring attestation for passkeys will effectively lock out every iPhone user - not going to happen. | | |
| ▲ | ori_b 9 days ago | parent [-] | | And I come back to: if it would never work, why not drop support? "We pinky promise" is just not good enough. | | |
| ▲ | growse 8 days ago | parent | next [-] | | > if it would never work, why not drop support? Because passkeys are designed to replace passwords across multiple different service contexts, that have different requirements. Just because there's no reason to use it for one use case doesn't mean it's not actually useful in a different one. See things like FIPS140 (which everyone ignores unless they're legally required not to). Can you sketch out for me the benefit of a public-facing service deciding to require passkey attestation? What's the thought process? Why would they decide to wake up and say "I know, I'm going to require that all of my users authenticate just with a Yubikeys and nothing else"? | | |
| ▲ | ori_b 8 days ago | parent [-] | | > Can you sketch out for me the benefit of a public-facing service deciding to require passkey attestation? What's the thought process? A misguided administrator is very likely to think "They can't use a malicious device to access our service". What's the benefit for a private service? |
| |
| ▲ | bryan_w 8 days ago | parent | prev [-] | | Is there a difference? It's a field in the response payload that nobody is filling out except the corps that need it. Would it make you feel better if they moved it to an appendix and called it an optional extension? | | |
| ▲ | lmm 8 days ago | parent | next [-] | | > Would it make you feel better if they moved it to an appendix and called it an optional extension? That kind of thing can make a huge difference once this standard starts becoming e.g. required for government procurement. | |
| ▲ | ori_b 8 days ago | parent | prev [-] | | As long as it required an extension and extra application. I should need to install an enterprise authenticator app, which speaks webpki-enterprise, if you want to enable that shit. |
|
|
|
|
|
|
|
|
|
|
| |
| ▲ | pas 9 days ago | parent | prev [-] | | Great. At that point there will be a real market niche for people who (can, want, might) think a bit different. |
|
| |
| ▲ | the_mitsuhiko 9 days ago | parent | prev | next [-] | | > Do you have some examples where people actually require attestation in 3rd party facing systems? Austria's governmental ID is linked to 5 approved tokens only. | |
| ▲ | rstuart4133 8 days ago | parent | prev | next [-] | | > Do you have some examples where people actually require attestation in 3rd party facing systems? That's not the right question. The right question is "what companies would be using passkey's if there was attestation on their security". To answer that question, you might look at the answer for a similar one on X509: "would we be doing banking over http if X509 didn't have attestation?". | |
| ▲ | nyeah 9 days ago | parent | prev [-] | | Seems very argumentative for somebody who's just saying there's no issue. |
|
|
| ▲ | FuriouslyAdrift 9 days ago | parent | prev | next [-] |
| We've had massive problems with moving to passkeys (browser based) at our company and moved back to an app based Authenticator. Everyone is accepting of the autenticator app or uses a yubikey. |
| |
| ▲ | janfromdaito 9 days ago | parent | next [-] | | What were those "massive problems"? | | |
| ▲ | FuriouslyAdrift 9 days ago | parent | next [-] | | Re-imaged, lost, or bad updates on PCs wiping out a all the saved passkeys and being locked out of all accounts during off-campus sales or design meetings. Making staff look like idiots in front of clients is a resume-generating-event. | | |
| ▲ | kube-system 9 days ago | parent [-] | | Yeah, 'availability' is a huge pillar of computer security that many people forget exists. |
| |
| ▲ | rstuart4133 9 days ago | parent | prev [-] | | I'm not the OP, but I expect it the same issues that have stopped me from using passkeys now. His reply does give one aspect of it: passkey's are fragile. To be secure, they can't be copied around or written down on a piece of paper in case you forget, so when the hardware they are stored on dies, or you lose your Yubikey or is as he described the PC re-imaged, all the your logins die. That will never fly, and it's why passkeys are having a hard time being adopted despite them being better in every other way. Passkey's solution to that is to make them copyable, but not let the user copy them. Instead someone else owns them, someone like Google or Apple, and they will do the copy to devices they approve of. That will only be to devices they trust to keep them secure I guess. But surprise, surprise, the only devices Apply will trust are ones sold to you by Apple. The situation is the same for everyone else, so as far as I know bitwarden will not let you copy a bitwarden key to anyone else. Bitwarden loudly proclaims they lets you export all your data, including TOTP - but that doesn't apply to passkeys. So, right now, having a passkey means locking yourself into proprietary companies ecosystem. If they company goes belly up, or Google decides you've transgressed one of the many pages of terms, or you decide to move to the Apple ecosystem again you lose all your logins. And again, that won't fly. The problem is not technological, it's mostly social. It's not difficult to imagine a ecosystem that does allow limited, and secure transfer and/or copying of passkeys. DNS has such a system for example. Anyone can go buy a DNS name, then securely move it between all registrars. There could be a similar system for passkeys. Passkeys have most of the bits in place. You need attestation, so whoever is relying on the key knows it's secure. The browsers could police attestation as they do now for CA's. We have secure devices that can be trusted to not leak leak passkeys in the form of phones, smartwatches, and hardware tokens. But we don't have a certification system for such devices. And we we don't have is a commercial ecosystem of companies willing to sell you safe passkey storage that allows copying to other such companies. On the technological front, we need standards for such storage, standards that ensure the companies holding the passkeys for you couldn't leak the secrets in the passkeys even if they were malicious. We are at a frustrating point of being 80% of the way there, but the remaining 20% looks to be harder than the first 80%. |
| |
| ▲ | gcr 9 days ago | parent | prev [-] | | i'm also curious to hear what issues you faced! |
|
|
| ▲ | johncolanduoni 9 days ago | parent | prev | next [-] |
| Why would BigTech care about the dozens of users using an open source password manager? What’s their gain from preventing these people from logging in? They love money and don’t care about user freedom, sure. But they’ve shown no evidence of hating user freedom on principle. Every time I’ve seen them actually attack user freedom, there was an embarrassingly obvious business angle. Like Chrome’s browser attestation that was definitely not to prevent Adblock, no sir. |
| |
| ▲ | xg15 9 days ago | parent | next [-] | | Because they'd actively have to make their proprietary passkey systems interoperable with password managers. This is fail-closed, not fail-open: If they truly didn't care, they'd also be no incentive for them to implement support. But I fear it's worse. Based on how past open standards played out, I find it believable they do care - that there won't be an open ecosystem of password managers. > But they’ve shown no evidence of hating user freedom on principle. Yes, they did, just see Microsoft's crusade against Linux and the origin of the "embrace-extend-extinguish" term. | | |
| ▲ | johncolanduoni 8 days ago | parent [-] | | They already failed then. All sides (browser->website and browser->passkey holder) of passkeys are open standards. They already don’t restrict passkeys from e.g. open source apps they have no control over, for both Google accounts and any site on Chrome. Webauthn “fails open” by default in the sense you’re indicating; if you don’t check the attestation, any app or device made by anyone can hold a passkey. I haven’t encountered or heard of anyone restricting passkey apps/hardware outside of business-managed employee accounts. I recommend reading the MDN docs on Webauthn, they’re surprisingly accessible. > Yes, they did, just see Microsoft's crusade against Linux and the origin of the "embrace-extend-extinguish" term. The whole point of the trial that term came from was that Microsoft explicitly saw Linux as a material threat to their business. What threat are Google quashing by preventing you from using passkeys they don’t control? |
| |
| ▲ | 63stack 9 days ago | parent | prev | next [-] | | >Why would BigTech care about the dozens of users using an open source password manager? Because big tech loves control. Just because you can't see the angle yet, it doesn't mean there isn't one now, or won't be one later. It has been shown time and time again that they will take all the freedom away from you that they can. | | |
| ▲ | johncolanduoni 8 days ago | parent [-] | | What instance have you seen where BigTech opted for control with no monetary incentive? | | |
| ▲ | 63stack 8 days ago | parent [-] | | There is already an example of Microsoft selling passkeys with their own "secure (tm)" stamp on them, and not accepting anything else just a few comments down. Even if there wasn't already an example, it's easy to turn control into a revenue stream at a later time. | | |
| ▲ | johncolanduoni 8 days ago | parent [-] | | That is for their enterprise SaaS, and has an obvious profit motive (I.e. bundling). Do you think Chrome is going to start charging for using their passkey storage and then kick all the other apps off Chrome? > Even if there wasn't already an example, it's easy to turn control into a revenue stream at a later time. I think you’ll have to justify or qualify this a bit. If Google forces every website on Chrome to have a red background, how do they turn that control into a revenue stream later on? | | |
| ▲ | 63stack 8 days ago | parent [-] | | Saying "oh that's enterprise" is just moving the goal posts. Chrome has already started kicking off extensions, see ublock. I can't divine the future about how they will further their income streams. | | |
| ▲ | johncolanduoni 8 days ago | parent [-] | | No it’s not. My goalpost from the beginning was “show me an example where there wasn’t a clear monetary incentive for restricting user freedom”. That one has a monetary incentive (make our paying customer for product X also buy product Y). As for blocking things that block ads; if you can’t see the monetary incentive for Google there then I don’t know what to tell you. I didn’t ask you to divine the future. I said “I’ve not seen them do X without trying to get Y” (a statement about the past), and you still haven’t given me a remotely credible example. | | |
| ▲ | fc417fc802 7 days ago | parent [-] | | You will almost always be able to find a way to derive a monetary advantage from any given arbitrary restriction of user freedom. Thus your claimed goalposts are essentially pointless. | | |
| ▲ | johncolanduoni 6 days ago | parent [-] | | Come on, I didn't come up with some 4D chess logic to impute a monetary advantage. In the examples people gave me, it was things like bundling (the oldest trick in the monopolist book) and ensuring that users look at your ads. Do you really think that if Chrome gets sued for blocking uBlock, that discovery won't find 1000 memos from executives and PMs at Google talking about how much money ensuring users have to see their ads would make? | | |
| ▲ | fc417fc802 6 days ago | parent | next [-] | | Fair point, it's less immediately obvious. Still I don't see where 4D chess is necessary. Some levers let you make money directly. The effective use of others is more opaque but if you hoard enough of them you will presumably be able to figure something out. Where's the direct monetary incentive to interfere with end users installing a modified Android image? What about SafetyNet? At absolute minimum you can use it to influence the perception of your brand as being the gold standard. | |
| ▲ | 63stack 6 days ago | parent | prev [-] | | Respectfully, you don't seem to understand the full picture on this. |
|
|
|
|
|
|
|
| |
| ▲ | bryanrasmussen 9 days ago | parent | prev | next [-] | | >Why would BigTech care about the dozens of users using an open source password manager? I agree, why would BigTech care about those dozens of users. Screw those guys, they can use our password manager or they can get lost, we don't need them! | | |
| ▲ | johncolanduoni 8 days ago | parent [-] | | They already let the open source password managers work just fine with every facet of passkeys. Why would they reverse this now, was my point. |
| |
| ▲ | withinboredom 9 days ago | parent | prev [-] | | > Why would BigTech care about the dozens of users using an open source password manager? Bots using a custom password manager to share logins. | | |
| ▲ | tux3 9 days ago | parent [-] | | If all you want is to make a bot that can use passkeys automatically, add a transistor between your Yubikey's touch button and GND. When you turn the transistor on, the capacitive sensor is activated. Now the Yubikey is just an API you can call, websites cannot tell the difference. You can't export keys, but a bot can add new keys after using existing keys to log in. | | |
| ▲ | withinboredom 9 days ago | parent [-] | | this doesn't work on stolen aws accounts though /s | | |
| ▲ | jrockway 9 days ago | parent [-] | | You can proxy all the underlying USB communications to a physical device. Allowing attestation in the spec was not an anti-bot measure. |
|
|
|
|
|
| ▲ | otterley 9 days ago | parent | prev | next [-] |
| I'm not sure I understand all the opposition expressed in this thread about device attestation. Can someone explain it to me? |
|
| ▲ | poemxo 8 days ago | parent | prev | next [-] |
| I thought Apple decided not to utilize the attestation field, is this not true? |
|
| ▲ | dathinab 9 days ago | parent | prev | next [-] |
| yeah, IMHO the design was messed up by a few very influential companies "over fitting" it for their company specific needs but I don't think attestation per-se is bad, if you are a employee from a company and they provide you the hardware and have special certification requirements for the hardware then attestation is totally fine at the same time normal "private" users should never exposed to it, and for most situations where companies do expose users to it (directly or indirectly) it's often not much better then snake oil if you apply a proper thread analysis (like allowing banking apps to claim a single app can provide both the login and second factor required by law for financial transactions, except if you do a thread analysis you notice the main thread of the app is a malicious privilege escalation, which tend to bypass the integrity checks anyway) But a lot of the design around attestation look to me like someone nudged it into a direction where "a nice enterprise features" turns into a "system to suppress and hinder new competition". It also IMHO should never have been in the category of "supported by passkey" but idk. "supported by enterprise passkey only" instead. Through lets also be realistic the degree to which you can use IT standards to push consumer protection is limited, especially given that standard are made by companies which foremost act in their financial interest, hence why a working consumer protection legislation and enforcement is so important. But anyway it's not just the specific way attestation is done, it's also that their general design have dynamics push to a consolidation on a view providers, and it's design also has elements which strongly push for "social login"/"SSO" instead of a login per service/app/etc. i.e. also pushes for consolidation on the side of login. And if you look at some of the largest contributors you find - those which benefit a ton from a consolidation of login into a few SSO providers - those which benefit from a different from a login consolidation (consolidation of password managers) and have made questionably blog entries to e.g. push people to not just store password but also 2FA in the same password manager even through that does remove on of the major benefits of 2FA (making the password manager not a single point of failure) - those which benefit a ton if it's harder for new hardware security key companies, especially such wich have an alternative approach to doing HSKs and somehow we ended up with a standard which "happened" to provide exactly that eh, now I sound like a conspiracy theorist, I probably should clarify that I don't think there had to be some nefarious influence, just this different companies having their own use case and over fitting the design on their use case would also happen to archive the same and is viable to have happened by accident |
| |
| ▲ | nobody9999 9 days ago | parent [-] | | >but I don't think attestation per-se is bad, if you are a employee from a company and they provide you the hardware and have special certification requirements for the hardware then attestation is totally fine Perhaps I'm missing something, but I do think hardware "attestation per-se is bad. Just look at the debacle of SafetyNet/Play Integrity, which disadvantages non-Google/non-OEM devices. Hardware attestation is that on steroids. As for corporate/MDM managed environments, what's wrong with client certificates[0] for "attestation"? They've been used securely and successfully for decades. As for the rest of your comment, I think you're spot on. Thanks for sharing your thoughts! [0] https://en.wikipedia.org/wiki/Client_certificate |
|
|
| ▲ | lijok 9 days ago | parent | prev [-] |
| Your style of thinking is exactly why linux never became a leader in desktop os's. Why we're still dealing with the most ridiculous tech debt and complexity in OSS tooling to date. You're obsessed with fake problems that have no bearing on real people. When grandma does indeed loose all her money because some prick phished her password away, I would love to watch you explain how that's actually better than BigTech taking away user freedoms. |
| |
| ▲ | dare944 9 days ago | parent | next [-] | | This argument is ridiculous and purposefully inflammatory. The issue at hand is the requirement for client attestation while using passkeys. So in that light, can you describe for us the scenario in which grandma, who is undoubtedly using passkeys on an iPhone or an Android, looses all her money simply because someone, somewhere else is using a passkey without attestation? You can't, because the vendor lock-in created by attestation doesn't meaningfully increase grandma's security. Rather, it exists (outside the enterprise scenario) primarily as an anti-competitive tool to be wielded by the major players. Passkeys could have been an overall boon to society. But with attestation restricted to a set of corporate-blessed providers it is a Faustian bargain at best. | | |
| ▲ | timmyc123 9 days ago | parent | next [-] | | > The issue at hand is the requirement for client attestation while using passkeys. There is no attestation in the consumer synced passkey ecosystem. Period. | | |
| ▲ | vdqtp3 8 days ago | parent [-] | | Can you say "There will be no attestation in the consumer synced passkey ecosystem. Period."? That seems to be the concern, not what exists today. | | |
| ▲ | timmyc123 8 days ago | parent [-] | | Ecosystems are made up of hundreds of thousands of organizations, billions of devices,and billions of users. How do you expect a single person to be able to make an authoritative statement like that? | | |
| ▲ | anonymars 7 days ago | parent [-] | | Well, you said definitively it's not in the...ecosystem, well of course it's not in that ecosystem now, but that's an extremely narrow reading of the question: the concern is it being in the spec that the consumer-facing ecosystem is pushing hard. A consumer-facing ecosystem that has amply demonstrated how much it loves lock-in. "Fool me once...can't get fooled again" |
|
|
| |
| ▲ | 9 days ago | parent | prev [-] | | [deleted] |
| |
| ▲ | achierius 9 days ago | parent | prev [-] | | You're the one dismissing real problems like "lose all passkeys when you lose your phone". | | |
| ▲ | lijok 9 days ago | parent | next [-] | | That is not a problem that GP brought up. In fact GP claims it's not a big problem. > The problems of Passkeys are more nuanced than just losing access when a device is lost (which actually doesn't need to happen depending on your setup). | |
| ▲ | otterley 9 days ago | parent | prev [-] | | That doesn’t happen when you use Apple’s passwords ecosystem or 1Password. The backing databases are synchronized between devices. | | |
| ▲ | bccdee 9 days ago | parent [-] | | And everyone knows that abuelitas in the global south, as a rule, own iPhone 16s and subscribe to 1Password. | | |
|
|
|
