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.
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.
Go to the playstation. Can’t login anymore. Passkey not supported.
It's too early for grandma to use, IMO.
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.
Depends on the brand of the passkey i think.
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?
As I said, it just works with iPhones and Yubikeys.
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.
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.
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.
B2C I would expect more latitude on requiring attestation.
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.
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.
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.
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.
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.
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.
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).
People forget that one of the purposes of authentication is to protect both the end user and the service operator.
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.
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.
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?)
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.
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.
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.
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.
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.
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.
> 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.
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."
This is already possible today. And since it's a completely open ecosystem, you can even build your own credential manager if you choose!
>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.
We have already been through this with many services suddenly demanding that you give them your phone number "for security".
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.
There are a bunch of service provider contexts where credential storage attestation is a really useful (and sometimes legally required!) feature.
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.
> It seems like the requirements already diverged.
No, the requirements are _contextual_. This isn't a new idea.
What makes you think that the Webauthn standards are _only_ "targeted at running services for the general public"?
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.
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.
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"?
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?
That kind of thing can make a huge difference once this standard starts becoming e.g. required for government procurement.
I should need to install an enterprise authenticator app, which speaks webpki-enterprise, if you want to enable that shit.
Austria's governmental ID is linked to 5 approved tokens only.
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?".
Making staff look like idiots in front of clients is a resume-generating-event.
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%.
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.
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.
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?
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.
Even if there wasn't already an example, it's easy to turn control into a revenue stream at a later time.
> 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?
Chrome has already started kicking off extensions, see ublock.
I can't divine the future about how they will further their income streams.
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.
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.
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!
Bots using a custom password manager to share logins.
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.
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
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!
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.
There is no attestation in the consumer synced passkey ecosystem. Period.
How do you expect a single person to be able to make an authoritative statement like that?
> 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).
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=G...
As does Windows: https://blogs.windows.com/windowsdeveloper/2024/10/08/passke...