KeePassXC pull request to add basic support for WebAuthn

To my knowledge, Apple has ripped out their "anonymous attestation" service together with introducing Passkeys in iOS 16; before that, requesting attestation was an option to opt out of Passkey syncing (and create a device-bound credential).

What would such a guarantee look like? It's very hard to promise that something will never happen.

I guess some kind of industry standard for criteria that a pass key manager must meet, and platforms accepting pass keys would promise to support any system meeting those criteria?

Trying to predict every future gets hard. There are unlikely but possible scenarios where we would want something like KeePassXC to be cut off (e.g. they or a similar product steals credentials).

The first and most straightforward reason is that we have no standard for importing/exporting passwords in or out of password managers, yet we manage to export them just fine. Each vault has its own proprietary format that's simple enough for others to implement as well.

But more importantly, WebAuthn makes assumptions about the characteristics of an authenticator at registration time. (And establishes continuity of those signals with DPK). Exporting it would be contrary to that.

Instead, with all these password manager vendors not wanting to be left out, and a good portion of the userbase either not being entirely in a single vendor's ecosystem, I can see cross-platform virtual authenticators like KeepassXC here becoming more common, and I don't think it's unlikely that the OSs will offer APIs to back these keys with TPMs/Secure Enclaves, and will allow you to replace the built-in passkey manager with a third-party, much like they do with password managers today.

I see it more in the purview of OS APIs than FIDO itself. The big, nontrivial risk here is that it involves establishing trust between devices across ecosystems so that they can share wrapped key material, and this introduces a vector for attacks. A user could more easily be tricked into trusting a malicious TPM that exfiltrates they passkeys, whereas single vendors like Apple can implement mitigations as long as all the devices are in their own ecosystem and they can use their own services for sync.

The U2F keys made by Yubikey are indeed OK from a privacy and lock-in perspective.

But the new latest thing from Google+Microsoft+Apple is 'passkeys' or 'passwordless' authentication, where you won't have a password. Two-factor authentication will be device+biometric, with the biometrics performed on the device. 'The device' in this case will be your smartphone, or windows PC with TPM. Or maybe a biometric yubikey for 0.01% of users.

They've also fixed one of the big usability stumbling blocks of U2F, by allowing your credentials to be synchronized to your cloud account - so even if you lose your iphone you won't be locked out of your account, you can just buy a new iphone and restore the backup. And of course, you can't expect to restore the backups to incompatible devices - that might let attackers bypass the biometrics.

It's fairly obvious why Microsoft would like people to not have passwords, and to log into websites using something locked to Windows and their Microsoft account.

See a lot of the comments in this thread as an example: https://news.ycombinator.com/item?id=35801392

Im pretty confident MS, Apple, Google will be pushing for their implementations to be the only accepted form of this authentication. It's not like their isn't precedent for this suspicion. And while it's not immediately obvious how these companies can use this technology to track you doesn't mean it can't be done or that they aren't working on it.

YET. Remember when LastPass was the second coming liberating us from the devils of Google passwords?

But even for "classical" WebAuthn it's still a valid issue.

The problem lies in:

1. attestation

2. browsers like chrome possible gate-keeping what can work as an authentication device (independent of attestation)

Attestation is a feature where each "batch" of authentication devices get a unique certificate burned in and report that back when registering a key through webauthn. There will be roughly at most 10_000 other people with the same cert. In many cases likely less.

And that is _highly_ problematic for many reasons. First while 10_000 sounds big, with just a bit additional fingerprinting information it allows a very unique fingerprinting of people across services (and devices you use to access the services). The combination of cert id + e.g. email + service + optional statistics about usability is _very_ saleable information, I mean a private health care provider would love to know that someone who might be one of their customers has signed up for a online anonymous alcoholic group or similar. They don't even need to know it's them for sure, just knowing it could be them with a 10% chance is enough to make sure to bump what their client has to pay "just to be save" the next chance the provider gets to do so.

Furthermore this are "burned in" certs so you can't have a different attestation certificate per service or anything like this without also having different physical devices, which in case of e.g. using your phone might be hard.

This "burned in" nature also means that some things can't have attestation, e.g. KeyPassXC or the TKey by nature can't (nor do want to) have this form of attestation. In turn if attestation is required this vendors are basically out of business.

But this isn't where the problems stop, attestation can also be used to find out what kind of device you have in general including an approximate date of production. So now the page you auth against knows you use a specific kind of YubiKey or e.g. that you use a specific phone produced in some specific time frame for authentication. This is very useful information for marketing as e.g. lifestyle and believes often influence buying decisions, not necessary in the current HSK market, but on the phone market which with passkey will likely become the most common HSK.

Furthermore this information can be used to remove agency from the user, e.g. through attestation a app can know that your HSK does support bio-metric authentication and in turn might force you to use it, even through you might not be able to do so because e.g. the fingerprint reader is broken or you had an op which makes face recognition impossible.

Lastly attestation allows applications to not work with HSK vendors they don't like even if they are standard conform. E.g. if Microsoft has beef with YubiKey they could reject them and make it look like a bug. Or a app you have for work could decide that using any HSK which isn't their partner (or from themself) is only usable if you pay a premium or similar.

Now the good part is WebAuthn doesn't require attestation. You can set attestation to none, and this can be done for devices which support attestation, too. E.g. Firefox does so by default.

The problem is if even just a small number of the big players (e.g. Google + Microsoft) decide they do require attestation on all logins it could be game over for _any form of privacy preserving 2FA for good for ever_ (except if regulators step in). Worse through chrome and edge they can enforce requiring attestation for sides which do not want to enforce it and collect additional private information by sending the attestation information data to their ad-services. Don't forget that not to long ago edge had a bug which wasn't fixed for a long time which lead to it basically sending all links their user followed to bing, including magic sharing links like you e.g. know from google drive. So don't expect vendors to not a

And for the big players enforcing attestation through the ecosystem is as easy as flipping a switch. As most HSKs support attestation. Furthermore they could add additional requirements, like only accepting attestation from vendors which have gone through some very expensive security review done by companies of their choice (Google already does so for access to (large pars of) their oauth2 authenticated APIs). This could mean good-by to any smaller or new HSK vendors, and might majorly hurt phone vendors they don't like.

Now you might wonder why attestation exist if it's that bad. The reason is requirements for some enterprises like e.g. military contractors requiring FIPS certified devices. Attestation can be used to enforce this. It also can be used to e.g make sure your employees only use HSKs you gave to them.

IMHO the main problem I see is not that attestation does exist, but that it's often phrased as a good or desirable thing (instead of a necessary evil) by the groups pushing for WebAuthn/passkey making me believe that there is a extremely high risk of abuse of this feature by Google, Microsoft or similar in the not so distant future. Especially given that it can be monetary wise quite beneficial and could be forced down the throat of users without most realizing it.

I would prefer if attestation would by default always be off and the spec requiring vendors to support non-attested devices as long as the user (or company the user belongs to) doesn't require it. Require that attestation information must be enabled on the key instead of being enabled by default, etc. I.e. make it cumbersome enough so that it can't easily be abused but still usable for the rare military contractor like use case. Oh and also there should be ways to have more privacy preserving attestation, too.

EDIT: To be clear you don't have the whole cert with all device information burned in, but a private key + some metadata and you can look up all this information based on the metadata depending on the kind of attestation. I.e. it works similar to TPM attestation, but not necessary exactly the same (expect if you used a TPM as HSK then it's exactly the same).

EDIT2: Just to be clear WebAuthn is in general a grate idea and could even lead to more privacy if used nicely. But it sadly has also potential for abuse and the parts which allow abuse can't be stripped out for practical reasons. So I'm worried.

EDIT3: WebAuthn today is mostly used for second factor in 2FA but it has the potential to become the first factor or fully take over both factors. Providing a more secure and convenient experience. But if abused also enforce more control of big cooperation, leak ton of private information (especially to the big cooperation's) and remove agency from the user in a not really acceptable way.

EDIT4: China could use attestation internally to even more control their citizens if they want to (might not be worth the effort), e.g. requiring vendors to be whitelisted (hint: vendor leaks private keys to government) or coupling the citizen score to it in some way.

At the end of the day pragmatism will survive. Sure, if the OP cant put a simple SIM card to get it resolved then he/she can buy from nitrokey/other installed GrapheneOS.

The basic premise of all these authentication/fingerprint/passkeys/whatever is to benefit the COMMON public. Telling a mother of 3 to keep keypassxc backup elsewhere (in a RAID with 3-2-1 offsite is impractical).

Also all these experts that write in HN often join some company and implement closed-source. Yes, life sucks if one uses 'linux' phone

- Banks don't care - If one is so against passkey gang then they should do something to make sure an average mum can use tech safely - see the state of PGP (very complex) - but signal/whatsapp is awesome. - Whether or not you like Cisco DUO becomes more of less default - Github/gitlab is developers world. Sure codeberg exists: I opened an issue asking them if they can help me configure runners - no help at all. - Also many of the devs say all open/free/etc but finally they do consume NetFlix, Prime etc (Yes, they have Apple TV or chromecast in addition to FrameWork (and RAID + 3-2-1). - Average Joe can't afford Framework. Get an ad-infested smartTV. Live with Google or Apple.

oauth/oidc gives too much signal to the identity providers. it's a 1990s solution at the time advertisers were writing the specs alone. and the implementation required oath-nascar-sponsorship pattern to have dozen of providers. no bank would accept that.

webauth is a spec of this time, were it's still owned by advendors, but with a couple device vendors now for a semblance of balance. and it also solve the implementation issue of having to show too many logos on the login page.

so, no, it wasn't possible before webauth. webauth solves the oauth issues for 3rd party attestation with a semblance of anonymity (which is meaningless if both party exchange data on back channels)

My guess is that the big groups will lobby for this to be turned into a checkbox in some "best practices" list that auditors will enforce into the usual suspects in the name of "safety and security": banks, shopping sites, government sites, etc.

They are still to officially publish a spec, but already published rate limits for 3rd party apps attested requests on the official docs and since 2021 people are documenting how they are updating their IDs on AAGUID fields on already available attested requests.

That can then be used to have a list of allowed devices if you really need hardware backed security for example (eg you provide all your users in your org with specific security keys and don't want them registering anything else). It's not recommended to use the attestation part unless you really need it though as it restricts user choice.

It is recommended that sites don't require it: "It is important to be aware that requiring attestation is an invasive policy, especially when used to restrict users' choice of authenticator. For some applications this is necessary; for most it is not. [...] When in doubt, err towards being more permissive, because using a passkey is more secure than not using a passkey. [...] we recommend that you do not require a trusted attestation unless you have specific reason to do so." https://developers.yubico.com/Passkeys/Passkey_relying_party...

More info: https://developer.mozilla.org/en-US/docs/Web/API/Web_Authent...