8 ms·

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 big

by t_mann 1y 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.

tialaramex 1y ago
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.
- lmm 1y ago
  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 1y ago
    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 1y ago
      > 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 1y ago
        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 1y ago
        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 1y ago
        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 1y ago
        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 1y ago
        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 1y ago
    - pas 1y ago
      Great. At that point there will be a real market niche for people who (can, want, might) think a bit different.
- 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 ago
    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 1y ago
      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 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 ago
        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.
- tux3 1y ago
  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/authentication/concept-fido2-hardware-vendor 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.
  - rcxdude 1y ago
    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 1y ago
      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 1y ago
        Same has been happening for for a few months. I get thrown out of all o365 services multiple times each day.
        wkat4242 1y ago
        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.
- the_mitsuhiko 1y ago
  > 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.
- account42 1y ago
  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".
- nyeah 1y ago
  Seems very argumentative for somebody who's just saying there's no issue.
- lelandbatey 1y ago
  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#issuecomment-1994673954 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.
  - timmyc123 1y ago
    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 1y ago
      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.
- rstuart4133 1y ago
  > 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?".
johncolanduoni 1y ago
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.
- withinboredom 1y ago
  > 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 1y ago
    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 1y ago
      this doesn't work on stolen aws accounts though /s
      - jrockway 1y ago
        You can proxy all the underlying USB communications to a physical device. Allowing attestation in the spec was not an anti-bot measure.
- 63stack 1y ago
  >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.
FuriouslyAdrift 1y ago
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 1y ago
  What were those "massive problems"?
  - FuriouslyAdrift 1y ago
    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 1y ago
      Yeah, 'availability' is a huge pillar of computer security that many people forget exists.
  - rstuart4133 1y ago
    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%.
lijok 1y ago
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.
- achierius 1y ago
  You're the one dismissing real problems like "lose all passkeys when you lose your phone".
  - otterley 1y ago
    That doesn’t happen when you use Apple’s passwords ecosystem or 1Password. The backing databases are synchronized between devices.
    - bccdee 1y ago
      And everyone knows that abuelitas in the global south, as a rule, own iPhone 16s and subscribe to 1Password.
      - otterley 1y ago
        There's no need to be snippy. Those are the solutions I'm familiar with; there may be others. If Android and Windows don't already solve this problem in similar ways--which they might!--it sounds like an open opportunity for them. Edit: sure enough, Android supports it: https://support.google.com/chrome/answer/13168025?hl=en&co=GENIE.Platform%3DAndroid https://support.google.com/chrome/answer/13168025?hl=en&co=G... As does Windows: https://blogs.windows.com/windowsdeveloper/2024/10/08/passkeys-on-windows-authenticate-seamlessly-with-passkey-providers/ https://blogs.windows.com/windowsdeveloper/2024/10/08/passke...
  - lijok 1y ago
dathinab 1y ago
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
abustamam 1y ago
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 1y ago
  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 1y ago
    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.
- palata 1y ago
  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 1y ago
    That might be the delta. I'm not using a hardware key (well, not a YubiKey). I'm using just my phone or browser.
otterley 1y ago
I'm not sure I understand all the opposition expressed in this thread about device attestation. Can someone explain it to me?
djrenren 1y ago
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.
poemxo 1y ago
I thought Apple decided not to utilize the attestation field, is this not true?

by t_mann 1y ago

tialaramex 1y ago

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.

lmm 1y ago
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 1y ago
  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 1y ago
    > 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 1y ago
      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 1y ago
        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 1y ago
        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 1y ago
        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 1y ago
        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 1y ago
  - pas 1y ago
    Great. At that point there will be a real market niche for people who (can, want, might) think a bit different.
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 ago
  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 1y ago
    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 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 ago
      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.
tux3 1y ago
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/authentication/concept-fido2-hardware-vendor 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.
- rcxdude 1y ago
  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 1y ago
    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 1y ago
      Same has been happening for for a few months. I get thrown out of all o365 services multiple times each day.
      - wkat4242 1y ago
        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.
the_mitsuhiko 1y ago
> 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.
account42 1y ago
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".
nyeah 1y ago
Seems very argumentative for somebody who's just saying there's no issue.
lelandbatey 1y ago
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#issuecomment-1994673954 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.
- timmyc123 1y ago
  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 1y ago
    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.
rstuart4133 1y ago
> 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?".

johncolanduoni 1y ago

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.

withinboredom 1y ago
> 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 1y ago
  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 1y ago
    this doesn't work on stolen aws accounts though /s
    - jrockway 1y ago
      You can proxy all the underlying USB communications to a physical device. Allowing attestation in the spec was not an anti-bot measure.
63stack 1y ago
>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.

FuriouslyAdrift 1y ago

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 1y ago
What were those "massive problems"?
- FuriouslyAdrift 1y ago
  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 1y ago
    Yeah, 'availability' is a huge pillar of computer security that many people forget exists.
- rstuart4133 1y ago
  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%.

lijok 1y ago

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.

achierius 1y ago
You're the one dismissing real problems like "lose all passkeys when you lose your phone".
- otterley 1y ago
  That doesn’t happen when you use Apple’s passwords ecosystem or 1Password. The backing databases are synchronized between devices.
  - bccdee 1y ago
    And everyone knows that abuelitas in the global south, as a rule, own iPhone 16s and subscribe to 1Password.
    - otterley 1y ago
      There's no need to be snippy. Those are the solutions I'm familiar with; there may be others. If Android and Windows don't already solve this problem in similar ways--which they might!--it sounds like an open opportunity for them. Edit: sure enough, Android supports it: https://support.google.com/chrome/answer/13168025?hl=en&co=GENIE.Platform%3DAndroid https://support.google.com/chrome/answer/13168025?hl=en&co=G... As does Windows: https://blogs.windows.com/windowsdeveloper/2024/10/08/passkeys-on-windows-authenticate-seamlessly-with-passkey-providers/ https://blogs.windows.com/windowsdeveloper/2024/10/08/passke...
- lijok 1y ago

dathinab 1y ago

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

abustamam 1y ago

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 1y ago
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 1y ago
  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.
palata 1y ago
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 1y ago
  That might be the delta. I'm not using a hardware key (well, not a YubiKey). I'm using just my phone or browser.

otterley 1y ago

I'm not sure I understand all the opposition expressed in this thread about device attestation. Can someone explain it to me?

djrenren 1y ago

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.

poemxo 1y ago

I thought Apple decided not to utilize the attestation field, is this not true?