KeePassXC pull request to add basic support for WebAuthn(github.com)
github.com
KeePassXC pull request to add basic support for WebAuthn
https://github.com/keepassxreboot/keepassxc/pull/8825
200 comments
It's a huge first step, but only a first step.
We still need:
- Guaranteess that attestation won't be used to block KeePassXC from being used as an authenticator. (Edit: it's been pointed out below that Apple is getting rid of attestation for its platform authenticators, and as far as I can tell that's true. Extremely big deal because nobody is going to want to cut off Apple keys, which effectively means those services can't require attestation. So assuming it is true (which it looks to be) this shouldn't be an issue.)
- Support for platform authenticators on Linux for Firefox and Chrome (Chrome currently has "no plans" to support this).
- Compatibility with other platform authenticators.
That last point is possibly the biggest problem, and it's part of why I've been pushing that this needs to be part of the spec. Okay, let's say you can export and import from KeePassXC. To where? This is still going to be a situation where a family member tells me they're interested in switching to Android and I have to tell them that they'll have to one-by-one transfer their login information. This is still going to be a situation where if you export your keys from KeePassXC, you won't be able to import them into anywhere. It'll still be a situation where if a family member loses their iPhone and they haven't synced keys to other devices already, their only solution is to buy another iPhone like a good little consumer.
That's not to say that an Open implementation of a platform authenticator doesn't matter. It absolutely does, it's just only a first step. We still need buy-in from the FIDO alliance itself that importing/exporting keys is an important part in general of being a passkey provider.
And we still need to see how the attestation situation is going to play out (see note above) and whether there are going to be any consequences at all for sites that just try to block anything except mainstream devices (see note above, the consequence would be losing iPhone users).
We still need:
- Guaranteess that attestation won't be used to block KeePassXC from being used as an authenticator. (Edit: it's been pointed out below that Apple is getting rid of attestation for its platform authenticators, and as far as I can tell that's true. Extremely big deal because nobody is going to want to cut off Apple keys, which effectively means those services can't require attestation. So assuming it is true (which it looks to be) this shouldn't be an issue.)
- Support for platform authenticators on Linux for Firefox and Chrome (Chrome currently has "no plans" to support this).
- Compatibility with other platform authenticators.
That last point is possibly the biggest problem, and it's part of why I've been pushing that this needs to be part of the spec. Okay, let's say you can export and import from KeePassXC. To where? This is still going to be a situation where a family member tells me they're interested in switching to Android and I have to tell them that they'll have to one-by-one transfer their login information. This is still going to be a situation where if you export your keys from KeePassXC, you won't be able to import them into anywhere. It'll still be a situation where if a family member loses their iPhone and they haven't synced keys to other devices already, their only solution is to buy another iPhone like a good little consumer.
That's not to say that an Open implementation of a platform authenticator doesn't matter. It absolutely does, it's just only a first step. We still need buy-in from the FIDO alliance itself that importing/exporting keys is an important part in general of being a passkey provider.
And we still need to see how the attestation situation is going to play out (see note above) and whether there are going to be any consequences at all for sites that just try to block anything except mainstream devices (see note above, the consequence would be losing iPhone users).
Do Passkeys even support attestation? What would they even attest to, given that the credential is effectively not bound to any secure hardware?
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).
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).
I'd love some kind of reference for this. I'm hoping you're right.
My understanding is that iOS does still very much support attestation (https://support.apple.com/guide/deployment/managed-device-at...) but I would be very happy to be proven wrong about that. I think attestation is harmful and should never have been part of the spec.
> What would they even attest to, given that the credential is effectively not bound to any secure hardware?
Originally at least, passkeys did support attestation in the form of reporting which authenticator had issued the passkey. Again, I would love for that to change. If Apple went full-anonymous with its passkeys and did not even sign the request to verify it was coming from an Apple device, that would be a really big deal for me. It would effectively make it impossible for any serious service to block anonymous attestation.
But my guess is that they probably just eased up on the hardware part of it and that they're still allowing requests to ask if the key is coming from an Apple device. Again, if anyone has documentation proving me wrong, please share it. I would love to check off the attestation problem from my list.
My understanding is that iOS does still very much support attestation (https://support.apple.com/guide/deployment/managed-device-at...) but I would be very happy to be proven wrong about that. I think attestation is harmful and should never have been part of the spec.
> What would they even attest to, given that the credential is effectively not bound to any secure hardware?
Originally at least, passkeys did support attestation in the form of reporting which authenticator had issued the passkey. Again, I would love for that to change. If Apple went full-anonymous with its passkeys and did not even sign the request to verify it was coming from an Apple device, that would be a really big deal for me. It would effectively make it impossible for any serious service to block anonymous attestation.
But my guess is that they probably just eased up on the hardware part of it and that they're still allowing requests to ask if the key is coming from an Apple device. Again, if anyone has documentation proving me wrong, please share it. I would love to check off the attestation problem from my list.
In my tests Apple refuses to provide attestation. I'm using Resident Key: required, User Verification: required and Authenticator Attachment left empty. With those settings registering a credential fails if I ask for attestation: "indirect" or "direct". Only "none" works.
My theory is that setting Authenticator Attachment to "cross-platform" (yubikeys and such) or "platform" (touch/face ID) might block cloud-synced credentials, in which case perhaps attestation: "indirect" still works. But I'm just guessing, I haven't tried it.
Or perhaps Apple anonymous attestation only works when using webauthn as a second factor (i.e. without Resident Key and/or without User Verification).
My theory is that setting Authenticator Attachment to "cross-platform" (yubikeys and such) or "platform" (touch/face ID) might block cloud-synced credentials, in which case perhaps attestation: "indirect" still works. But I'm just guessing, I haven't tried it.
Or perhaps Apple anonymous attestation only works when using webauthn as a second factor (i.e. without Resident Key and/or without User Verification).
I think Apple just scrapped it entirely with iOS 16 for a more consistent user experience.
Unfortunately, this also makes it a dealbreaker for me – I want some credentials to be device-bound and non-extractable.
Unfortunately, this also makes it a dealbreaker for me – I want some credentials to be device-bound and non-extractable.
> Unfortunately, this also makes it a dealbreaker for me – I want some credentials to be device-bound and non-extractable.
Why do you need attestation to have that? You can still use a Yubikey and the like, if nothing else.
Or do you mean that you want to force the users of your service to only use credentials that are device-bound and non-extractable, I suppose. But then I would ask... why?
Why do you need attestation to have that? You can still use a Yubikey and the like, if nothing else.
Or do you mean that you want to force the users of your service to only use credentials that are device-bound and non-extractable, I suppose. But then I would ask... why?
Both, actually.
As an RP, due to regulatory or security requirements, for example:
Knowing whether I need to worry about my users' iCloud and Google accounts having been taken over or not is important for accurately evaluating the security posture of any service built on Passkeys as an authentication factor.
And as a user, I don’t trust Apple's or Google's sync backends enough to store my most important credentials there. Especially iCloud is frighteningly easy to hijack, even with a recovery code in place (which ironically at the same time increases the chance I’ll lock myself out as the legitimate user).
As an RP, due to regulatory or security requirements, for example:
Knowing whether I need to worry about my users' iCloud and Google accounts having been taken over or not is important for accurately evaluating the security posture of any service built on Passkeys as an authentication factor.
And as a user, I don’t trust Apple's or Google's sync backends enough to store my most important credentials there. Especially iCloud is frighteningly easy to hijack, even with a recovery code in place (which ironically at the same time increases the chance I’ll lock myself out as the legitimate user).
> And as a user, I don’t trust Apple's or Google's sync backends enough to store my most important credentials there
I'm not sure everyone realizes that you don't get a choice whether or not Apple passkeys are synced to iCloud, you can't create a passkey from Safari unless iCloud syncing is turned on.
Regardless of whether or not there's support for exporting/importing, you should as a user have the option to not send your passkeys to iCloud. That is a completely reasonable ask. There's really no system where synchronizing to the cloud and syncing between devices/ecosystems ought to be required for the user. I want users to have that option and I have some disagreements about whether services should be able to block it, but I do want it to be an option rather than a requirement.
My guess is that Apple is worried people will turn off syncing without knowing the implications, but... it should still be the user's choice. It's completely legitimate for someone to be annoyed about forced sync.
I'm not sure everyone realizes that you don't get a choice whether or not Apple passkeys are synced to iCloud, you can't create a passkey from Safari unless iCloud syncing is turned on.
Regardless of whether or not there's support for exporting/importing, you should as a user have the option to not send your passkeys to iCloud. That is a completely reasonable ask. There's really no system where synchronizing to the cloud and syncing between devices/ecosystems ought to be required for the user. I want users to have that option and I have some disagreements about whether services should be able to block it, but I do want it to be an option rather than a requirement.
My guess is that Apple is worried people will turn off syncing without knowing the implications, but... it should still be the user's choice. It's completely legitimate for someone to be annoyed about forced sync.
That vombined with the key-escrow for iCloud would be a deal breaker for me if I'm understanding you right.
My main issue with attestation is that it's platform controlled instead of user-controlled and that it doesn't just bind a credential to a device, it binds an authentication mechanism to a category/subset of devices.
If the attestation part was separated from the manufacturer and it couldn't be used to identify who made the device or what brand the device was or what OS it was running, and instead was just a completely randomized device key with no other information with only the restriction that it was hardware-bound, would that be enough to meet your use case or would the user being able to update the OS/firmware still be a problem for you?
My problems with attestation in order:
1. Locking down the ability of the user to change the software/firmware.
2. Allowing the website to identify the device/manufacturer (and allowing them to restrict accounts to a subset of devices).
3. Not allowing the user to replicate/change the device/move the key.
But 1 and 2 are the biggest issues I have, if they went away then 3 wouldn't be as big of a deal to me. Not that I would be super-happy about it, I still don't think it would be a good idea, but... it's comparatively less of a problem.
I could imagine a version of this where you get one private key set on firmware/OS load for your device but it's completely random, and if you update the firmware and the integrity check fails the only thing that happens is that key changes to a new one and the old key is erased. So updating the firmware would invalidate the old login keys that were relying on attestation, but it would not make it possible for a site to block an un-Googled Android from making an account or to even know that you were using an Android/iOS device in the first place.
Again, I don't think that would be a good idea, I think it would be introducing a lot of foot-guns that shouldn't be exposed to ordinary users, but I don't think it would be nearly as much of a problem as saying "we guarantee this is one of X devices in this hardware batch, and that the OS hasn't been customized."
If the attestation part was separated from the manufacturer and it couldn't be used to identify who made the device or what brand the device was or what OS it was running, and instead was just a completely randomized device key with no other information with only the restriction that it was hardware-bound, would that be enough to meet your use case or would the user being able to update the OS/firmware still be a problem for you?
My problems with attestation in order:
1. Locking down the ability of the user to change the software/firmware.
2. Allowing the website to identify the device/manufacturer (and allowing them to restrict accounts to a subset of devices).
3. Not allowing the user to replicate/change the device/move the key.
But 1 and 2 are the biggest issues I have, if they went away then 3 wouldn't be as big of a deal to me. Not that I would be super-happy about it, I still don't think it would be a good idea, but... it's comparatively less of a problem.
I could imagine a version of this where you get one private key set on firmware/OS load for your device but it's completely random, and if you update the firmware and the integrity check fails the only thing that happens is that key changes to a new one and the old key is erased. So updating the firmware would invalidate the old login keys that were relying on attestation, but it would not make it possible for a site to block an un-Googled Android from making an account or to even know that you were using an Android/iOS device in the first place.
Again, I don't think that would be a good idea, I think it would be introducing a lot of foot-guns that shouldn't be exposed to ordinary users, but I don't think it would be nearly as much of a problem as saying "we guarantee this is one of X devices in this hardware batch, and that the OS hasn't been customized."
This would be great, but as it is, platform authenticators are effectively always a combination of trusted and untrusted hardware/software, since the TEE or Secure Element usually does not have user input/output capabilities and is relying to the application processor OS's integrity to some extent.
Notable exception: Google's Protected Confirmation [1] – the signature format of that is not natively WebAuthN/FIDO compatible, though.
[1] https://android-developers.googleblog.com/2018/10/android-pr...
Notable exception: Google's Protected Confirmation [1] – the signature format of that is not natively WebAuthN/FIDO compatible, though.
[1] https://android-developers.googleblog.com/2018/10/android-pr...
https://www.slashid.dev/blog/passkeys-deepdive/ talks about this, among others.
I think Apple mentions it in a WWDC presentation as well, but I find it quite ridiculous to bury such a significant change in a video + transcript announcement.
I think Apple mentions it in a WWDC presentation as well, but I find it quite ridiculous to bury such a significant change in a video + transcript announcement.
Well heck, I'm very happy you chimed in on this, thanks. Very happy surprise.
To be honest, I think as it is, not providing attestation was the only way to not outright be in violation of the FIDO/WebAuthN specifications (which at the moment requires specifying whether a key is "stored inside secure hardware", for which there is no good answer for synchronized credentials), but I don't think we're in the clear yet:
Nothing prevents the big platform players (who are major contributors to the WebAuthN specification) from introducing a new form of attestation that specifically allows expressing that a credential is synced. I could absolutely imagine this happening in WebAuthn Level 3, FIDO CTAP 2.2 etc.
Nothing prevents the big platform players (who are major contributors to the WebAuthN specification) from introducing a new form of attestation that specifically allows expressing that a credential is synced. I could absolutely imagine this happening in WebAuthn Level 3, FIDO CTAP 2.2 etc.
I think the use case for attestation is for devices that were designed to prevent key export, like YubiKey, that are selected by a corporation for internal use where they want to ensure that employees self-enroll only the approved authenticators.
I don't see much reason for syncing platform authenticators to attest because the keys will ultimately wind up elsewhere beyond the attested device.
I don't see much reason for syncing platform authenticators to attest because the keys will ultimately wind up elsewhere beyond the attested device.
I think that's something that I'd be fine with -- you can require a YubiKey (or similar) within an org if you need on-device credentials, but general platform authenticators and syncing authenticators don't provide attestation. So in practice your choice is to either:
- require a roaming authenticator (ie, a hardware token) which can be enforced with attestation, or
- don't use attestation
I'd still like it to be reflected in the spec that platform authenticators should not support attestation, but it seems like a reasonable compromise to me. Enterprises still can do what they want and have strong security internally, but Netflix can't use attestation unless they're willing to force every one of their customers to buy a hardware token and to block web sign-in on Mac. Honestly, kind of a win-win for everyone (except for companies that wanted to abuse the spec).
I'm not against enterprise customers and orgs being able to control their own devices, I just want guarantees that the practice will stay within those companies/orgs. And restricting the capability to basically just roaming authenticators/hardware tokens seems like it would provide some guarantee.
- require a roaming authenticator (ie, a hardware token) which can be enforced with attestation, or
- don't use attestation
I'd still like it to be reflected in the spec that platform authenticators should not support attestation, but it seems like a reasonable compromise to me. Enterprises still can do what they want and have strong security internally, but Netflix can't use attestation unless they're willing to force every one of their customers to buy a hardware token and to block web sign-in on Mac. Honestly, kind of a win-win for everyone (except for companies that wanted to abuse the spec).
I'm not against enterprise customers and orgs being able to control their own devices, I just want guarantees that the practice will stay within those companies/orgs. And restricting the capability to basically just roaming authenticators/hardware tokens seems like it would provide some guarantee.
> I think attestation is harmful and should never have been part of the spec.
I agree. That it's part of the spec makes me nervous about the spec.
I agree. That it's part of the spec makes me nervous about the spec.
The entire sync fabric would become the authenticator. Apple and Google could (but don't currently) issue attestation that the passkey ecosystem you're using is theirs for multi-device passkeys, and continue to use attestation for the specific hardware for DPK and single-device passkeys.
> Guaranteess that attestation won't be used to block KeePassXC from being used as an authenticator.
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).
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).
> 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?
Basically what I would want. Or (better) for attestation to just not be a part of the spec in the first place. I don't think services should have the choice of cutting off authenticators.
See sibling comments though, if Apple refuses to support attestation for platform keys, then requiring attestation effectively means cutting off the iPhone market, which is the next best thing to getting rid of attestation entirely.
Basically what I would want. Or (better) for attestation to just not be a part of the spec in the first place. I don't think services should have the choice of cutting off authenticators.
See sibling comments though, if Apple refuses to support attestation for platform keys, then requiring attestation effectively means cutting off the iPhone market, which is the next best thing to getting rid of attestation entirely.
I don't think FIDO saying importing/exporting keys is important and them having to standardize it is the same thing.
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 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 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.
Sort of. Passwords themselves are just text, and they can always be copied and pasted no matter what. But you're right that the full vaults themselves aren't standardized, and a requirement in the spec that authenticators just generally support export would be enough for me I think, even if it didn't specify a specific format.
I do think specifying a specific format might be better though -- if we had standardized password vaults more, maybe the LastPass breach wouldn't have happened, and they wouldn't have assumed that encrypting site metadata/urls was optional. But I generally agree, supporting multiple export formats is fine as long as those export formats exist in some form.
> 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.
Well, that's the question though: should it make assumptions about the characteristics of an authenticator? Embedded in that statement is the idea that sites should have more insight into my device than they've ever had in the past. It's a huge expansion of the amount of information that a site has about where a user is logging in from. I don't know that I agree with that, and I think there needs to be more justification that having that information leads to practical increases in security.
There are a lot of advantages to WebAuthn that have nothing to do with verifying the device. The biggest security increase from WebAuthn is the site identifying itself to the authenticator. The site getting information about the hardware is kind of secondary, and I would argue of much more limited value for security (but of high value for DRM/platform restrictions).
Users can already get device-bound credentials without attestation -- they can get a Yubikey. So for users that want that extra security, options exist. But does it add tangible security for the site to be in charge of that? Enough security to justify enabling some really pervasive DRM methods and device lock-down?
> 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.
I don't think I agree with this either. Any restriction Apple puts in front of iCloud recovery can be put in front of an export button. Any information that Apple asks you before syncing to a new iPhone can be asked before providing you with a backup file. And from an attacker's point of view, if I can attack the iCloud export function, I can also buy an iPhone and attack its device recovery process. I'm not sure there is much of a security difference here.
I think that ship has kind of sailed as soon as we start talking about syncing passkeys between devices. I think this argument only makes sense if we get of sync entirely and say, "no, they'll be completely device-bound like a Yubikey." But if Apple is syncing keys between iOS and Mac, if it allows going even further and sharing them using AirDrop, we're well past the point of worrying about whether someone can trick you into exporting your passkeys.
Sort of. Passwords themselves are just text, and they can always be copied and pasted no matter what. But you're right that the full vaults themselves aren't standardized, and a requirement in the spec that authenticators just generally support export would be enough for me I think, even if it didn't specify a specific format.
I do think specifying a specific format might be better though -- if we had standardized password vaults more, maybe the LastPass breach wouldn't have happened, and they wouldn't have assumed that encrypting site metadata/urls was optional. But I generally agree, supporting multiple export formats is fine as long as those export formats exist in some form.
> 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.
Well, that's the question though: should it make assumptions about the characteristics of an authenticator? Embedded in that statement is the idea that sites should have more insight into my device than they've ever had in the past. It's a huge expansion of the amount of information that a site has about where a user is logging in from. I don't know that I agree with that, and I think there needs to be more justification that having that information leads to practical increases in security.
There are a lot of advantages to WebAuthn that have nothing to do with verifying the device. The biggest security increase from WebAuthn is the site identifying itself to the authenticator. The site getting information about the hardware is kind of secondary, and I would argue of much more limited value for security (but of high value for DRM/platform restrictions).
Users can already get device-bound credentials without attestation -- they can get a Yubikey. So for users that want that extra security, options exist. But does it add tangible security for the site to be in charge of that? Enough security to justify enabling some really pervasive DRM methods and device lock-down?
> 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.
I don't think I agree with this either. Any restriction Apple puts in front of iCloud recovery can be put in front of an export button. Any information that Apple asks you before syncing to a new iPhone can be asked before providing you with a backup file. And from an attacker's point of view, if I can attack the iCloud export function, I can also buy an iPhone and attack its device recovery process. I'm not sure there is much of a security difference here.
I think that ship has kind of sailed as soon as we start talking about syncing passkeys between devices. I think this argument only makes sense if we get of sync entirely and say, "no, they'll be completely device-bound like a Yubikey." But if Apple is syncing keys between iOS and Mac, if it allows going even further and sharing them using AirDrop, we're well past the point of worrying about whether someone can trick you into exporting your passkeys.
WebAuthn goes to great lengths to preserve user privacy, much more so than past alternatives, so I don't think there's a expansion of information, especially when the device is probed for capabilities which is extremely pervasive with browsers today. There is some new info with attestation, but other than it not being very widespread in practice, attestation keys are shared by a minimum of 100k devices.
In general, the intent of attestation seems to be enterprise use cases where companies want to issue authenticators that meet certain capabilities, and only allow those capabilities as attested by a trusted party. For instance, a company might mandate Webauthn with user verification for their internal systems, and they don't want an employee using a software based virtual authenticator that fakes UV and keeps key material in plain text, so they issue Yubikeys to their staff and only allow Yubikeys to be used for logging in (issued or otherwise, as the RP can't differentiate them). I have not seen a single instance of attestation being used to gatekeep access to an otherwise public service, but I'd like to see some examples if there are any. Enterprise attestation is a different beast, however, and can uniquely identify an individual security key, but this has significant management overhead and will not be seen outside of enterprise use cases.
Now I understand you personally don't value attestation as highly as some other features of WebAuthn and that's fine, I'm on the same boat. However that's the nature of standards and how they come about, there's multiple interests in the working groups. It's hard to say what's the "biggest" security increase because that's entirely relative to the individual or corporation implementing, consuming, or standarizing the functionality.
As to whether there can be a phishing-resistant trust-establishment mechanism, I absolutely agree that there can be. All I'm saying is that there isn't an interoperable one currently, and that it's hard to establish interoperability across vendors and without an online sync fabric (I'd presume most users would want to export key material to a file or otherwise not rely necesarily on a third party phone-home service to export keys). I also think that it exceeds the scope of FIDO and will have to be primarily OS-vendor-driven. For me, personally, this along with something like the recovery extension that Yubico is promoting is one of the potential future features I'm most excited about.
Related, and for the other reason why import/export is hard, which is the reasoning about the ecosystem, I don't think that even with such a mechanism we'll ever be able to export keys out if iCloud Keychain and into KeePassXC. What will most likely happen is that credentials generated by KeePaasXC and backed by hardware, will be able to be imported/exported in/out of devices in the same trust circle, using a KeePassXC sync fabric as the sync mechanism.
In general, the intent of attestation seems to be enterprise use cases where companies want to issue authenticators that meet certain capabilities, and only allow those capabilities as attested by a trusted party. For instance, a company might mandate Webauthn with user verification for their internal systems, and they don't want an employee using a software based virtual authenticator that fakes UV and keeps key material in plain text, so they issue Yubikeys to their staff and only allow Yubikeys to be used for logging in (issued or otherwise, as the RP can't differentiate them). I have not seen a single instance of attestation being used to gatekeep access to an otherwise public service, but I'd like to see some examples if there are any. Enterprise attestation is a different beast, however, and can uniquely identify an individual security key, but this has significant management overhead and will not be seen outside of enterprise use cases.
Now I understand you personally don't value attestation as highly as some other features of WebAuthn and that's fine, I'm on the same boat. However that's the nature of standards and how they come about, there's multiple interests in the working groups. It's hard to say what's the "biggest" security increase because that's entirely relative to the individual or corporation implementing, consuming, or standarizing the functionality.
As to whether there can be a phishing-resistant trust-establishment mechanism, I absolutely agree that there can be. All I'm saying is that there isn't an interoperable one currently, and that it's hard to establish interoperability across vendors and without an online sync fabric (I'd presume most users would want to export key material to a file or otherwise not rely necesarily on a third party phone-home service to export keys). I also think that it exceeds the scope of FIDO and will have to be primarily OS-vendor-driven. For me, personally, this along with something like the recovery extension that Yubico is promoting is one of the potential future features I'm most excited about.
Related, and for the other reason why import/export is hard, which is the reasoning about the ecosystem, I don't think that even with such a mechanism we'll ever be able to export keys out if iCloud Keychain and into KeePassXC. What will most likely happen is that credentials generated by KeePaasXC and backed by hardware, will be able to be imported/exported in/out of devices in the same trust circle, using a KeePassXC sync fabric as the sync mechanism.
> There is some new info with attestation, but other than it not being very widespread in practice, attestation keys are shared by a minimum of 100k devices.
I would question whether 100k devices is actually a big enough pool to protect privacy. Regardless, that is "an expansion of information", right? It's a pretty decent fingerprinting vector to start with when combined with other device information.
> For instance, a company might mandate Webauthn with user verification for their internal systems, and they don't want an employee using a software based virtual authenticator that fakes UV and keeps key material in plain text
At the point where a company is in that position, they should be supplying their own locked down devices. This is an extremely narrow use case, much more narrow than "I'd like to be able to use this on a Linux machine." And the companies that are in that position have much greater resources to solve that problem by issuing dedicated hardware that's locked down in general. It doesn't need to be part of the spec.
In practice, where this will be used most often is with banking apps, which I've argued elsewhere are not nearly responsible enough to be trusted with this extra information and are usually startlingly insecure. They can get on board with basic security techniques that the rest of the industry has already implemented before we discuss giving them more control over my hardware.
People keep billing this as a compromise, but it's not really. The attestation proponents are asking for a capability that doesn't exist, they're asking for a level of insight into my hardware that login methods have never provided before. The status quo is "no, of course you don't get that." If they want to change the status quo, asking for "compromise" isn't the way to do it, providing real proof that it's not going to be abused (which, I'll mention in a second I don't think is safe to assume) and that it'll provide meaningful security increases is where they should start.
> I have not seen a single instance of attestation being used to gatekeep access to an otherwise public service, but I'd like to see some examples if there are any.
Continuing from the above, I've seen both intent (https://developer.apple.com/forums/thread/708982) and practice (https://arstechnica.com/civis/threads/passwordless-google-ac...).
Also attestation in the form of SafetyNet (https://developer.android.com/training/safetynet/attestation) and the more recent Play Integrity API has been used for DRM in plenty of instances, even for very trivial services like Netflix. So it seems pretty reasonable to extrapolate out that services that already use attestation for DRM today are going to use it when it's available for WebAuthn.
The default assumption ought to be that this is going to be abused. Every instance of attestation in the past has been abused. Why would we just assume that suddenly companies are going to be nice about it?
> However that's the nature of standards and how they come about, there's multiple interests in the working groups.
Right, and the way you force that collaboration is by refusing to go along with standards that are harmful. I'm not part of this standards process, it's their job to build a standard that appeals to me if they want me to use it. If they can't do that, then I won't use it. And I'll advise other people not to use it and I'll tell people (truthfully) that I believe it's a harmful standard. As users/stakeholders, we force collaboration by laying out very clearly where our limits are so we can focus on finding solutions that solve multiple use-cases.
I'm willing to compromise on a lot of stuff. Not this. If the big stakeholders also aren't willing to compromise on it, then we'll stick with passwords. That's fine with me. The FIDO group doesn't have an inherent right to have people pay attention to them. It's their job to come up with a standard that's good enough that people want to pay attention to it.
> All I'm saying is that there isn't an interoperable one currently, and that it's hard to establish interoperability across vendors and without an online sync fabric
Some of us would argue that is also entirely the FIDO Alliance's problem to solve given that they exist to build the FIDO standard and are the most invested party in getting the rest of us to adopt their solution.
Normally when people get together to build Open standards, they start with an Open implementation as a proof of concept. FIDO Alliance seems to be under the impression that it's everyone else's problem that nobody has built an Open implementation of their "Open" spec for them. That's just not how this should work.
> and will have to be primarily OS-vendor-driven
It's a good thing that all of those OS-vendors are part of the FIDO Alliance and are currently involved in a process that provides them with a great opportunity to sit down with each other and hash this out then.
> What will most likely happen is that credentials generated by KeePaasXC and backed by hardware, will be able to be imported/exported in/out of devices in the same trust circle, using a KeePassXC sync fabric as the sync mechanism.
That wouldn't solve any of my problems; the sync fabric isn't the important part -- I want to control my own keys. What does an "Open" sync fabric that restricts keys to specific devices even look like? That's certainly not Open in the sense that I control the sync fabric or can compile/change it myself.
I would question whether 100k devices is actually a big enough pool to protect privacy. Regardless, that is "an expansion of information", right? It's a pretty decent fingerprinting vector to start with when combined with other device information.
> For instance, a company might mandate Webauthn with user verification for their internal systems, and they don't want an employee using a software based virtual authenticator that fakes UV and keeps key material in plain text
At the point where a company is in that position, they should be supplying their own locked down devices. This is an extremely narrow use case, much more narrow than "I'd like to be able to use this on a Linux machine." And the companies that are in that position have much greater resources to solve that problem by issuing dedicated hardware that's locked down in general. It doesn't need to be part of the spec.
In practice, where this will be used most often is with banking apps, which I've argued elsewhere are not nearly responsible enough to be trusted with this extra information and are usually startlingly insecure. They can get on board with basic security techniques that the rest of the industry has already implemented before we discuss giving them more control over my hardware.
People keep billing this as a compromise, but it's not really. The attestation proponents are asking for a capability that doesn't exist, they're asking for a level of insight into my hardware that login methods have never provided before. The status quo is "no, of course you don't get that." If they want to change the status quo, asking for "compromise" isn't the way to do it, providing real proof that it's not going to be abused (which, I'll mention in a second I don't think is safe to assume) and that it'll provide meaningful security increases is where they should start.
> I have not seen a single instance of attestation being used to gatekeep access to an otherwise public service, but I'd like to see some examples if there are any.
Continuing from the above, I've seen both intent (https://developer.apple.com/forums/thread/708982) and practice (https://arstechnica.com/civis/threads/passwordless-google-ac...).
Also attestation in the form of SafetyNet (https://developer.android.com/training/safetynet/attestation) and the more recent Play Integrity API has been used for DRM in plenty of instances, even for very trivial services like Netflix. So it seems pretty reasonable to extrapolate out that services that already use attestation for DRM today are going to use it when it's available for WebAuthn.
The default assumption ought to be that this is going to be abused. Every instance of attestation in the past has been abused. Why would we just assume that suddenly companies are going to be nice about it?
> However that's the nature of standards and how they come about, there's multiple interests in the working groups.
Right, and the way you force that collaboration is by refusing to go along with standards that are harmful. I'm not part of this standards process, it's their job to build a standard that appeals to me if they want me to use it. If they can't do that, then I won't use it. And I'll advise other people not to use it and I'll tell people (truthfully) that I believe it's a harmful standard. As users/stakeholders, we force collaboration by laying out very clearly where our limits are so we can focus on finding solutions that solve multiple use-cases.
I'm willing to compromise on a lot of stuff. Not this. If the big stakeholders also aren't willing to compromise on it, then we'll stick with passwords. That's fine with me. The FIDO group doesn't have an inherent right to have people pay attention to them. It's their job to come up with a standard that's good enough that people want to pay attention to it.
> All I'm saying is that there isn't an interoperable one currently, and that it's hard to establish interoperability across vendors and without an online sync fabric
Some of us would argue that is also entirely the FIDO Alliance's problem to solve given that they exist to build the FIDO standard and are the most invested party in getting the rest of us to adopt their solution.
Normally when people get together to build Open standards, they start with an Open implementation as a proof of concept. FIDO Alliance seems to be under the impression that it's everyone else's problem that nobody has built an Open implementation of their "Open" spec for them. That's just not how this should work.
> and will have to be primarily OS-vendor-driven
It's a good thing that all of those OS-vendors are part of the FIDO Alliance and are currently involved in a process that provides them with a great opportunity to sit down with each other and hash this out then.
> What will most likely happen is that credentials generated by KeePaasXC and backed by hardware, will be able to be imported/exported in/out of devices in the same trust circle, using a KeePassXC sync fabric as the sync mechanism.
That wouldn't solve any of my problems; the sync fabric isn't the important part -- I want to control my own keys. What does an "Open" sync fabric that restricts keys to specific devices even look like? That's certainly not Open in the sense that I control the sync fabric or can compile/change it myself.
100k devices is the minimum. Also I already agreed that this is an expansion of information, were it to be requested in practice and the user chose to provide it. And I don't believe the use case for attestation in enterprise settings is narrow. For the "own locked down devices" is that Enterprise Attestation exists, which has management overhead in both its configurations, wheras normal attestation does not.
I can't comment on the intent link, as there's no information. But the "practice" link is simply incorrect. Google does in fact allow a Yubikey to be used as a passkey, I have one configured myself. It shows up as "FIDO2 security key". What I assume is happening in that link you sent is that the user's yubikey does not have a PIN set for the FIDO2 interface, which means that it can't provide user verification and therefore is not a passkey as far as Google is concerned. This is the kind of reasoning about the capabilities of the authenticator that I was talking about, and it doesn't have to do with attestation.
> it's their job to build a standard that appeals to me if they want me to use it
They're appealing to OEMs, vendors and service providers as well. I also don't quite see how merely having attestation in the standard is harmful. RPs and users can chose not to require or provide it. If RPs decided they needed it for malicious purposes, would not having it in the standard suffice for them to be benign?
> That wouldn't solve any of my problems; the sync fabric isn't the important part -- I want to control my own keys.
It would, because then the sync fabric is free to provide you with an exported version that's wrapped in a key of your choosing. It's open in the sense that any one software can import/export keys out of hardware devices that are currently restricted to the hardware vendor.
I can't comment on the intent link, as there's no information. But the "practice" link is simply incorrect. Google does in fact allow a Yubikey to be used as a passkey, I have one configured myself. It shows up as "FIDO2 security key". What I assume is happening in that link you sent is that the user's yubikey does not have a PIN set for the FIDO2 interface, which means that it can't provide user verification and therefore is not a passkey as far as Google is concerned. This is the kind of reasoning about the capabilities of the authenticator that I was talking about, and it doesn't have to do with attestation.
> it's their job to build a standard that appeals to me if they want me to use it
They're appealing to OEMs, vendors and service providers as well. I also don't quite see how merely having attestation in the standard is harmful. RPs and users can chose not to require or provide it. If RPs decided they needed it for malicious purposes, would not having it in the standard suffice for them to be benign?
> That wouldn't solve any of my problems; the sync fabric isn't the important part -- I want to control my own keys.
It would, because then the sync fabric is free to provide you with an exported version that's wrapped in a key of your choosing. It's open in the sense that any one software can import/export keys out of hardware devices that are currently restricted to the hardware vendor.
> I also don't quite see how merely having attestation in the standard is harmful.
Because having it there makes it an option, and I think that history is pretty clear that if you give the tech industry a bat, they will beat their users with it sooner or later.
Because having it there makes it an option, and I think that history is pretty clear that if you give the tech industry a bat, they will beat their users with it sooner or later.
> This is the kind of reasoning about the capabilities of the authenticator that I was talking about, and it doesn't have to do with attestation.
It seems like it does though... correct me if I'm wrong, but attestation is how Google knows that it's a Yubikey and that it doesn't have a PIN/biometrics set. And in practice, it's not allowed to be used to provide user verification; there's a restriction on functionality. Yes, you can use it as a Yubikey, but you can't use it for the new passkey system.
> For the "own locked down devices" is that Enterprise Attestation exists, which has management overhead in both its configurations, wheras normal attestation does not.
Good? Attestation should have an overhead. Getting rid of the overhead is exactly what I don't want. You can have attestation today through existing methods, and they're basically sufficient for enterprises that need them. It costs a bit of money, which is good because it'll force enterprises to think about it. And importantly, it doesn't really work for restricting consumer accounts, it's mostly useful for orgs where devices are controlled. Which is again, good, that's the best outcome. Enterprises can restrict their devices, but there are barriers to entry that prevent those restrictions from being applied to general consumers using their own devices.
The other thing you can do if you don't want to go the hardware route is you can have a custom login app for your enterprise. You shouldn't, you should provide users with devices if you're going to restrict those devices -- but there's nothing stopping an org from having a custom authenticator that works outside of the standard.
The only problem they'll have is if they want general users outside of the org to install that app just to log in. Which again, is very good. It's good that you can build a custom solution for within an enterprise, but that there are significant challenges in front of trying to force that solution on regular users.
Heck, you can even use the Play Integrity API to help. Should the Play Integrity API exist? No, probably not. But it does and it's usable for dedicated authenticators, so we certainly don't need another solution on top of it.
This is a rare use-case, and it's probably fine for the orgs that need it to use something other than passkeys. There's no real danger to them of lock-out, they're already doing this today so they can just keep doing what they're already doing.
> I also don't quite see how merely having attestation in the standard is harmful.
Because every single time that we've had attestation in the past -- literally every single time -- it's been used for DRM. Hopefully this conversation doesn't matter because Apple is just blocking attestation, but what do you see in the industry that makes you think this time would be different? Has something radically changed at Netflix over the past couple of years?
When has attestation ever not been abused?
Here's the Chromium team expressing similar fears: https://www.chromium.org/security-keys/ Are those fears unfounded? I don't generally assume that Google is going to be leading the charge on user freedom, and if even they are kind of creeped out about the potential here, then I trust that there's a real risk of abuse.
> It's open in the sense that any one software can import/export keys out of hardware devices that are currently restricted to the hardware vendor.
Right, but if you're talking about trusted devices, unless that's something the user controls, exporting/importing doesn't matter. The point is that the user should be able to export their key and import it to any authenticator they choose without fear that their authenticator is going to be blocked from logging in to a service.
It seems like it does though... correct me if I'm wrong, but attestation is how Google knows that it's a Yubikey and that it doesn't have a PIN/biometrics set. And in practice, it's not allowed to be used to provide user verification; there's a restriction on functionality. Yes, you can use it as a Yubikey, but you can't use it for the new passkey system.
> For the "own locked down devices" is that Enterprise Attestation exists, which has management overhead in both its configurations, wheras normal attestation does not.
Good? Attestation should have an overhead. Getting rid of the overhead is exactly what I don't want. You can have attestation today through existing methods, and they're basically sufficient for enterprises that need them. It costs a bit of money, which is good because it'll force enterprises to think about it. And importantly, it doesn't really work for restricting consumer accounts, it's mostly useful for orgs where devices are controlled. Which is again, good, that's the best outcome. Enterprises can restrict their devices, but there are barriers to entry that prevent those restrictions from being applied to general consumers using their own devices.
The other thing you can do if you don't want to go the hardware route is you can have a custom login app for your enterprise. You shouldn't, you should provide users with devices if you're going to restrict those devices -- but there's nothing stopping an org from having a custom authenticator that works outside of the standard.
The only problem they'll have is if they want general users outside of the org to install that app just to log in. Which again, is very good. It's good that you can build a custom solution for within an enterprise, but that there are significant challenges in front of trying to force that solution on regular users.
Heck, you can even use the Play Integrity API to help. Should the Play Integrity API exist? No, probably not. But it does and it's usable for dedicated authenticators, so we certainly don't need another solution on top of it.
This is a rare use-case, and it's probably fine for the orgs that need it to use something other than passkeys. There's no real danger to them of lock-out, they're already doing this today so they can just keep doing what they're already doing.
> I also don't quite see how merely having attestation in the standard is harmful.
Because every single time that we've had attestation in the past -- literally every single time -- it's been used for DRM. Hopefully this conversation doesn't matter because Apple is just blocking attestation, but what do you see in the industry that makes you think this time would be different? Has something radically changed at Netflix over the past couple of years?
When has attestation ever not been abused?
Here's the Chromium team expressing similar fears: https://www.chromium.org/security-keys/ Are those fears unfounded? I don't generally assume that Google is going to be leading the charge on user freedom, and if even they are kind of creeped out about the potential here, then I trust that there's a real risk of abuse.
> It's open in the sense that any one software can import/export keys out of hardware devices that are currently restricted to the hardware vendor.
Right, but if you're talking about trusted devices, unless that's something the user controls, exporting/importing doesn't matter. The point is that the user should be able to export their key and import it to any authenticator they choose without fear that their authenticator is going to be blocked from logging in to a service.
Attestation doesn't carry that information. Also consider that Apple zeroes out attestation for its devices and works just fine with Google as passkeys. What's happening here is that when an RP is registering an authenticator, it can include a property that's called userVerification which in a Yubikey is backed by a PIN, and Google sets it as required. The restriction in functionality that you mention is exactly what Google wants though, but not for malicious purposes. Google doesn't want someone stealing your yubikey and having that suffice to log in to your account. They want user verification so that if that Yubikey is stolen, an attacker also needs to know the PIN, thus providing two factors. Again, Google does not prevent you from using Yubikeys. It prevents you from using security keys that aren't configured for user verification, and they don't do that through attestation.
> Right, but if you're talking about trusted devices, unless that's something the user controls, exporting/importing doesn't matter. The point is that the user should be able to export their key and import it to any authenticator they choose without fear that their authenticator is going to be blocked from logging in to a service.
No, not just physical devices. Anything that represents a device with a wrapping key. That could be a software implementation that's just a file you control. What I'm saying though is that for the general case which is what a standard is concerned with, we won't see the standard-mandated ability to export passkeys across sync fabrics. I don't see a world where you can export passkeys from Apple iCloud Keychain and import them into Google Password Manager. But I do see a world where you create passkeys in your Mac with KeePassXC, and can use an open sync fabric from KeePassXC to sync them to your Android device, and a flat file as well, and I believe this will happen not under the purview of FIDO. Whether those flat files can then hop on to another sync fabric (say, 1Password) to later be imported into hardware devices will definitely not be a part of a standard, but given the analogy to password managers, it doesn't matter; those capabilities can still be built.
As far as the Chromium post, I find that one slightly more dystopic than attestation as a feature. They say If Chrome becomes aware that websites are not meeting these expectations, we may withdraw Security Key privileges from those sites, and similar other warnings. They don't say that they will warn users, they say that they will withdraw privileges. Do you want your browser deciding for you what websites you can log in to?
> Right, but if you're talking about trusted devices, unless that's something the user controls, exporting/importing doesn't matter. The point is that the user should be able to export their key and import it to any authenticator they choose without fear that their authenticator is going to be blocked from logging in to a service.
No, not just physical devices. Anything that represents a device with a wrapping key. That could be a software implementation that's just a file you control. What I'm saying though is that for the general case which is what a standard is concerned with, we won't see the standard-mandated ability to export passkeys across sync fabrics. I don't see a world where you can export passkeys from Apple iCloud Keychain and import them into Google Password Manager. But I do see a world where you create passkeys in your Mac with KeePassXC, and can use an open sync fabric from KeePassXC to sync them to your Android device, and a flat file as well, and I believe this will happen not under the purview of FIDO. Whether those flat files can then hop on to another sync fabric (say, 1Password) to later be imported into hardware devices will definitely not be a part of a standard, but given the analogy to password managers, it doesn't matter; those capabilities can still be built.
As far as the Chromium post, I find that one slightly more dystopic than attestation as a feature. They say If Chrome becomes aware that websites are not meeting these expectations, we may withdraw Security Key privileges from those sites, and similar other warnings. They don't say that they will warn users, they say that they will withdraw privileges. Do you want your browser deciding for you what websites you can log in to?
> Google doesn't want someone stealing your yubikey and having that suffice to log in to your account.
But it's not Google's place to make that decision for me.
But it's not Google's place to make that decision for me.
> Also consider that Apple zeroes out attestation for its devices
This may be the saving grace because it may end up being that whether or not attestation is part of the standard doesn't matter because companies won't be able to use it. But it doesn't mean that attestation is harmless, it means that we're very lucky that (for now) Apple is deciding to effectively make it impossible for a commercial service to actually use it reliably.
> It prevents you from using security keys that aren't configured for user verification, and they don't do that through attestation.
Fair point, I don't know that this is actually using attestation and that it's not just the Yubikey reporting back that it doesn't support that field. I do quibble somewhat with "they're not blocking Yubikeys, they're just blocking <description of a Yubikey>." But... yeah, I'll grant you're probably right that this is not using attestation.
> I don't see a world where you can export passkeys from Apple iCloud Keychain and import them into Google Password Manager.
That's exactly what I mean when I say it wouldn't be sufficient. When I talk about syncing, I'm talking about transferring into and out of ecosystems, not just specific devices. What you're describing is a system where I can use the KeePassXC ecosystem to use keys across multiple devices. But I can't transfer those keys out of the KeePassXC ecosystem (unless hopefully other vendors like 1Password add support), and if someone starts using iCloud, they're stuck with same vendor lock-in.
This is effectively saying, "you'll have a closed ecosystem for most people, but people who know enough beforehand to avoid it can somewhat avoid it." We should expect better from a standards body that purports to be building an Open standard.
I really don't see how this is an out-of-scope problem for the FIDO Alliance. They have input from every single major OS. All of the players are in the same space. And their entire job is to dictate how this is going to work. I'm just asking them to do that job. A spec for portability is not that big of an ask compared to everything else they're already working on as part of this.
It's not really that different than a spec for logging in using a standardized QR code, or over Bluetooth -- all of which was considered in-scope for them to to work on. Portability is just part of the general interoperability work that we should be expecting them to do.
> Do you want your browser deciding for you what websites you can log in to?
Of course not; in very typical fashion Google's solution to the problem may be worse than the problem itself. Google is very fond of recognizing that a feature is abusable and saying, "well, how about we prevent that abuse by giving ourselves even more capricious power?"
But I do think it shows I'm not being paranoid, that this is a legitimate worry that even Google recognizes is worth worrying about. Google is part of the FIDO Alliance and it's not looking at attestation as a theoretical risk; it's looking at it as a very plausible risk that it needs to have policies around.
Which I think is pretty reasonable given that every single instance of attestation in the past has been used for DRM, and there's nothing special about attestation in this spec that would stop that from happening. I really do think the burden of proof here is on you to describe why you think Netflix/Banks/etc... are suddenly going to act differently now than they have with every other attestation method they've had access to leading up to now.
The only answer I can think of is, "they'll act differently because Apple is effectively killing attestation for platform keys for everyone." But that's not really a defense of attestation, it's just something to thank Apple for.
This may be the saving grace because it may end up being that whether or not attestation is part of the standard doesn't matter because companies won't be able to use it. But it doesn't mean that attestation is harmless, it means that we're very lucky that (for now) Apple is deciding to effectively make it impossible for a commercial service to actually use it reliably.
> It prevents you from using security keys that aren't configured for user verification, and they don't do that through attestation.
Fair point, I don't know that this is actually using attestation and that it's not just the Yubikey reporting back that it doesn't support that field. I do quibble somewhat with "they're not blocking Yubikeys, they're just blocking <description of a Yubikey>." But... yeah, I'll grant you're probably right that this is not using attestation.
> I don't see a world where you can export passkeys from Apple iCloud Keychain and import them into Google Password Manager.
That's exactly what I mean when I say it wouldn't be sufficient. When I talk about syncing, I'm talking about transferring into and out of ecosystems, not just specific devices. What you're describing is a system where I can use the KeePassXC ecosystem to use keys across multiple devices. But I can't transfer those keys out of the KeePassXC ecosystem (unless hopefully other vendors like 1Password add support), and if someone starts using iCloud, they're stuck with same vendor lock-in.
This is effectively saying, "you'll have a closed ecosystem for most people, but people who know enough beforehand to avoid it can somewhat avoid it." We should expect better from a standards body that purports to be building an Open standard.
I really don't see how this is an out-of-scope problem for the FIDO Alliance. They have input from every single major OS. All of the players are in the same space. And their entire job is to dictate how this is going to work. I'm just asking them to do that job. A spec for portability is not that big of an ask compared to everything else they're already working on as part of this.
It's not really that different than a spec for logging in using a standardized QR code, or over Bluetooth -- all of which was considered in-scope for them to to work on. Portability is just part of the general interoperability work that we should be expecting them to do.
> Do you want your browser deciding for you what websites you can log in to?
Of course not; in very typical fashion Google's solution to the problem may be worse than the problem itself. Google is very fond of recognizing that a feature is abusable and saying, "well, how about we prevent that abuse by giving ourselves even more capricious power?"
But I do think it shows I'm not being paranoid, that this is a legitimate worry that even Google recognizes is worth worrying about. Google is part of the FIDO Alliance and it's not looking at attestation as a theoretical risk; it's looking at it as a very plausible risk that it needs to have policies around.
Which I think is pretty reasonable given that every single instance of attestation in the past has been used for DRM, and there's nothing special about attestation in this spec that would stop that from happening. I really do think the burden of proof here is on you to describe why you think Netflix/Banks/etc... are suddenly going to act differently now than they have with every other attestation method they've had access to leading up to now.
The only answer I can think of is, "they'll act differently because Apple is effectively killing attestation for platform keys for everyone." But that's not really a defense of attestation, it's just something to thank Apple for.
let me restate, they're not "blocking the description of a Yubikey" either. You can register one, and in fact I just did to try it out. The Yubikey needs to be configured with a PIN which you do through Yubikey manager. They're blocking authenticators that don't have additional protection other than just presence.
> That's exactly what I mean when I say it wouldn't be sufficient
I think we're confusing what the role of a standard is, versus what other features can be built around a standard capability. With an open fabric, vendors like KeePassXC can allow exports in formats that can then be imported by other sync fabrics as I described previously. The standard mandating it would be a good reason for vendors not to adopt the standard, or adopt a crippled version. Given the fact that WebAuthn ties capabilites to the authenticator at registration time I think it's understandable that vendors like Apple want give RPs assurance that keys are entirely contained in an ecosystem that guarantees those assertions. You will have options, including not using Apple/Microsoft/Google's sync fabrics, and to move off these sync fabrics if you consider them insufficient, but not by exporting keys directly.
> I really don't see how this is an out-of-scope problem for the FIDO Alliance (...) It's not really that different than a spec for logging in using a standardized QR code
Logging in using a QR code or BLE is part of the hybrid transport in CTAP, which deals with how authenticators communicate with clients. It's very much within FIDO. Establishing trust between devices in different ecosystems to form a circle of trust so that key material can be shared doesn't really have anything to do with logging in to services, so it's not WebAuthn. It also doesn't deal with client to authenticator communication as there's no client. If anything, a standard like TPM (ISO/IEC 11889) is a better fit, but probably too low level for that exact use case.
> Which I think is pretty reasonable given that every single instance of attestation in the past has been used for DRM
Going back to attestation, I don't think that in general it's in the best interest of services to not allow you to log in to them, but I can see a bank in their typical backwards-fashion issuing some branded keys and only letting you use those (Symantec, I'm looking at you). The reality is that standard or not, if RPs want this functionality, it'll be there. Standards simply attempt to provide the bare minimum for interoperability that every party can agree to. The alternative is not an attestation-free world. It's a bank asking you to log in with a flawed key they purchased from an ancient vendor because there's no standard offering that does what they want. I'd much rather have a Bank of America branded Yubikey with enterprise attestation using WebAuthn than some weak and poorly implemented proprietary token like the ones they issue today.
> That's exactly what I mean when I say it wouldn't be sufficient
I think we're confusing what the role of a standard is, versus what other features can be built around a standard capability. With an open fabric, vendors like KeePassXC can allow exports in formats that can then be imported by other sync fabrics as I described previously. The standard mandating it would be a good reason for vendors not to adopt the standard, or adopt a crippled version. Given the fact that WebAuthn ties capabilites to the authenticator at registration time I think it's understandable that vendors like Apple want give RPs assurance that keys are entirely contained in an ecosystem that guarantees those assertions. You will have options, including not using Apple/Microsoft/Google's sync fabrics, and to move off these sync fabrics if you consider them insufficient, but not by exporting keys directly.
> I really don't see how this is an out-of-scope problem for the FIDO Alliance (...) It's not really that different than a spec for logging in using a standardized QR code
Logging in using a QR code or BLE is part of the hybrid transport in CTAP, which deals with how authenticators communicate with clients. It's very much within FIDO. Establishing trust between devices in different ecosystems to form a circle of trust so that key material can be shared doesn't really have anything to do with logging in to services, so it's not WebAuthn. It also doesn't deal with client to authenticator communication as there's no client. If anything, a standard like TPM (ISO/IEC 11889) is a better fit, but probably too low level for that exact use case.
> Which I think is pretty reasonable given that every single instance of attestation in the past has been used for DRM
Going back to attestation, I don't think that in general it's in the best interest of services to not allow you to log in to them, but I can see a bank in their typical backwards-fashion issuing some branded keys and only letting you use those (Symantec, I'm looking at you). The reality is that standard or not, if RPs want this functionality, it'll be there. Standards simply attempt to provide the bare minimum for interoperability that every party can agree to. The alternative is not an attestation-free world. It's a bank asking you to log in with a flawed key they purchased from an ancient vendor because there's no standard offering that does what they want. I'd much rather have a Bank of America branded Yubikey with enterprise attestation using WebAuthn than some weak and poorly implemented proprietary token like the ones they issue today.
> They're blocking authenticators that don't have additional protection other than just presence.
I know this isn't strictly attestation, but this is blocking authentication based on attributes of the device, correct? I'm sort of quibbling over details here I know, but this is basically saying "we are checking for a pin protection or biometric protection and limiting how an authenticator is used based on the presence of that feature."
> You will have options, including not using Apple/Microsoft/Google's sync fabrics, and to move off these sync fabrics if you consider them insufficient, but not by exporting keys directly.
And that is a good reason to reject the standard as harmful.
I'd love to use keys for log-in, it would be a huge boost to security. But if portability between sync fabrics as you call them isn't supported, then we can stick with passwords. I'm fine with that, and I think other people are as well. Ultimately, passkeys have to be better than what we have, and out of luck or history or whatever reason password vaults are extremely portable between different ecosystems. Even ecosystems that try to lock down passwords struggle to do so, because ultimately passwords are text and in the worst case they can be copied and pasted between managers. So if passkeys aren't similarly portable and they become another tool for holding people down into a single OS ecosystem (even if there are options that allow avoiding that), then they're harmful -- the security gains are not worth the downside.
It does not address my concerns to say that a user who knows about the dangers of vendor lock-in in advance can avoid it in some situations.
> Establishing trust between devices in different ecosystems to form a circle of trust so that key material can be shared doesn't really have anything to do with logging in to services
It absolutely does, it dictates how that login information gets shared between devices. As far as I'm concerned it's just another part of transport.
It's also relevant to FIDO in the sense that it is a major barrier of entry to getting passkeys to be accepted by the general public. At the end of the day, the highest-level responsibility for FIDO is to figure out a standard that's usable. The lack of portability keeps the standard from being usable. It is the single biggest complaint that people have about passkeys.
Yes, that is a problem they should solve, particularly because everyone who would be required to be in the same room to solve that problem is currently in the same room, and all of them have a vested interest in getting rid of barriers to passkey adoption.
Ultimately, does FIDO want this to be adopted by normal people or not? If the answer is yes, then portability is a problem they need to tackle. Again, every single company required to tackle this problem is currently a member of that alliance.
> Standards simply attempt to provide the bare minimum for interoperability that every party can agree to.
That bare minimum of interoperability should not exist for abusive uses of the technology. Like you said, there are solutions for this today. Companies that are abusing their customers should not get extra support from OSes and standard bodies to help them do it.
Bank of America can already use a Yubikey today. Or they can use a poorly implemented proprietary token. And maybe if that goes badly for them, they'll use an actually more secure option instead of LARPing security.
But look, this is exactly what people said about web video DRM, it's exactly what people say every time these conversations around DRM and fingerprinting come up. Companies are going to fingerprint your device anyway, we might as well give them a device ID for advertising. Companies are going to build weird browser extensions, we might as well get rid of them and make DRM part of the spec. It's really just an excuse, the standards make it easier to do this stuff. They're pursued because they get rid of the inconvenient parts of abusing users. And in doing so, they remove a barrier of entry that should exist.
And integrating this into web browsers on desktop platforms is a huge gift to companies that want to do this. I already can't use my bank's app on a deGoogled phone but at least I can sign in on a web browser, because in the world that currently exists attestation through a general web browser is just difficult and just annoying enough that my bank isn't willing to do it. Please stop trying to change that.
When a company is doing something awful, it should have to leave the beaten path and work outside of the standard to do it. Because that helps us call out that they are doing something awful, and it helps us point to their solution and say, "no, that's not intended."
I know this isn't strictly attestation, but this is blocking authentication based on attributes of the device, correct? I'm sort of quibbling over details here I know, but this is basically saying "we are checking for a pin protection or biometric protection and limiting how an authenticator is used based on the presence of that feature."
> You will have options, including not using Apple/Microsoft/Google's sync fabrics, and to move off these sync fabrics if you consider them insufficient, but not by exporting keys directly.
And that is a good reason to reject the standard as harmful.
I'd love to use keys for log-in, it would be a huge boost to security. But if portability between sync fabrics as you call them isn't supported, then we can stick with passwords. I'm fine with that, and I think other people are as well. Ultimately, passkeys have to be better than what we have, and out of luck or history or whatever reason password vaults are extremely portable between different ecosystems. Even ecosystems that try to lock down passwords struggle to do so, because ultimately passwords are text and in the worst case they can be copied and pasted between managers. So if passkeys aren't similarly portable and they become another tool for holding people down into a single OS ecosystem (even if there are options that allow avoiding that), then they're harmful -- the security gains are not worth the downside.
It does not address my concerns to say that a user who knows about the dangers of vendor lock-in in advance can avoid it in some situations.
> Establishing trust between devices in different ecosystems to form a circle of trust so that key material can be shared doesn't really have anything to do with logging in to services
It absolutely does, it dictates how that login information gets shared between devices. As far as I'm concerned it's just another part of transport.
It's also relevant to FIDO in the sense that it is a major barrier of entry to getting passkeys to be accepted by the general public. At the end of the day, the highest-level responsibility for FIDO is to figure out a standard that's usable. The lack of portability keeps the standard from being usable. It is the single biggest complaint that people have about passkeys.
Yes, that is a problem they should solve, particularly because everyone who would be required to be in the same room to solve that problem is currently in the same room, and all of them have a vested interest in getting rid of barriers to passkey adoption.
Ultimately, does FIDO want this to be adopted by normal people or not? If the answer is yes, then portability is a problem they need to tackle. Again, every single company required to tackle this problem is currently a member of that alliance.
> Standards simply attempt to provide the bare minimum for interoperability that every party can agree to.
That bare minimum of interoperability should not exist for abusive uses of the technology. Like you said, there are solutions for this today. Companies that are abusing their customers should not get extra support from OSes and standard bodies to help them do it.
Bank of America can already use a Yubikey today. Or they can use a poorly implemented proprietary token. And maybe if that goes badly for them, they'll use an actually more secure option instead of LARPing security.
But look, this is exactly what people said about web video DRM, it's exactly what people say every time these conversations around DRM and fingerprinting come up. Companies are going to fingerprint your device anyway, we might as well give them a device ID for advertising. Companies are going to build weird browser extensions, we might as well get rid of them and make DRM part of the spec. It's really just an excuse, the standards make it easier to do this stuff. They're pursued because they get rid of the inconvenient parts of abusing users. And in doing so, they remove a barrier of entry that should exist.
And integrating this into web browsers on desktop platforms is a huge gift to companies that want to do this. I already can't use my bank's app on a deGoogled phone but at least I can sign in on a web browser, because in the world that currently exists attestation through a general web browser is just difficult and just annoying enough that my bank isn't willing to do it. Please stop trying to change that.
When a company is doing something awful, it should have to leave the beaten path and work outside of the standard to do it. Because that helps us call out that they are doing something awful, and it helps us point to their solution and say, "no, that's not intended."
I don't understand your point about vendor lock-in, on the devices side YubiCo, Feitian and NitroKey exist (as well as many others probably) and are none are "multinational corps" in the derogative sense (the replies make reference to Google, Microsoft, Apple -- do those companies even produce U2F tokens?). On the authentication side, WebAuthn isn't tied to SSO and most websites that have their own login system will probably just add WebAuthn rather than switching to SSO (the WebAuthn and FIDO sites both have PoCs you can test and there are plenty of open source libraries and frameworks to use).
I also don't get your point about how tokens could be used to sell your data -- it's my understanding that it'd be very difficult to track someone using their U2F key (there are attestation keys but they're done in batches so you cannot track an individual token, and the registration handshake doesn't use a unique ID you can use for tracking). But even ignoring that, if it were possible to track people using their token, then a digital token in KeePassXC would also be just as trackable.
Personally I don't see a huge difference between this KeePassXC feature and just having your password (and maybe OTP) stored in KeePassXC and auto-filling everything. I think that's also secure enough for the vast majority of people (it's also what I use for websites that don't support WebAuthn as a second factor or when I don't want to have to have a physical token to do actions) but it's clearly not a second factor of authentication. Requiring a physical token is sometimes a good thing. Yes, if it breaks it's annoying, but requiring a token is what makes it multi factor authentication.
I also don't get your point about how tokens could be used to sell your data -- it's my understanding that it'd be very difficult to track someone using their U2F key (there are attestation keys but they're done in batches so you cannot track an individual token, and the registration handshake doesn't use a unique ID you can use for tracking). But even ignoring that, if it were possible to track people using their token, then a digital token in KeePassXC would also be just as trackable.
Personally I don't see a huge difference between this KeePassXC feature and just having your password (and maybe OTP) stored in KeePassXC and auto-filling everything. I think that's also secure enough for the vast majority of people (it's also what I use for websites that don't support WebAuthn as a second factor or when I don't want to have to have a physical token to do actions) but it's clearly not a second factor of authentication. Requiring a physical token is sometimes a good thing. Yes, if it breaks it's annoying, but requiring a token is what makes it multi factor authentication.
> I don't understand your point about vendor lock-in, on the devices side YubiCo, Feitian and NitroKey exist (as well as many others probably) and are none are "multinational corps" in the derogative sense (the replies make reference to Google, Microsoft, Apple -- do those companies even produce U2F tokens?).
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.
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.
A passkey is just a "software yubikey". I highly recommend trying to implement a demo of this and you'll see how little difference there is between them unless you specifically go out of your way.
That's the point, if I'm reading this thread correctly. Google/Apple/Microsoft's implementation will be going out of their way to tie it specifically to a device and biometrics.
In fact, Google and Apple have recently started synchronizing Passkeys to the user‘s cloud account, which effectively undoes any specific device binding.
As a Relying Party, you can’t know what authentication method will be used for either enrolling a new device, or on the new device itself.
As a Relying Party, you can’t know what authentication method will be used for either enrolling a new device, or on the new device itself.
Yes, Google/Apple/Microsoft are likely to tie it to device biometrics, but:
- 1Password is rolling out Passkey support next month
- Apple is on the record stating that passkey import/export is on the roadmap
You can already use the 1Password demo and export the passkey it generates and see the raw data.
- 1Password is rolling out Passkey support next month
- Apple is on the record stating that passkey import/export is on the roadmap
You can already use the 1Password demo and export the passkey it generates and see the raw data.
Glad to hear Apple's allowing import/export. The issue I was thinking of is setting up passkeys for your phone and now you can't use it on desktop, or switching to Android/iOS and it can't carry over.
Isn’t tying specifically to a device and biometrics the point?
No. The point is replacing passwords with something which is equally user-friendly, but which cannot be phished.
Ie replacing passwords with cryptographic keys tied to a specific website.
That is, your passkey for amazon.com won’t work on a phishers site amozon.com or lookalike.somehost.org.
And in the hypothetical case of your passkey for site X being leaked it will never be the same as for site Y, so it’s not reusable.
No part of the specification requires Google, cloud or third party trust. Those are just “user-friendly” client-side implementations.
Ie replacing passwords with cryptographic keys tied to a specific website.
That is, your passkey for amazon.com won’t work on a phishers site amozon.com or lookalike.somehost.org.
And in the hypothetical case of your passkey for site X being leaked it will never be the same as for site Y, so it’s not reusable.
No part of the specification requires Google, cloud or third party trust. Those are just “user-friendly” client-side implementations.
> which is equally user-friendly, but which cannot be phished.
This is good to bring up. Without vendor lock-in and attestation, passkeys have huge benefits for blocking phishing attacks. It's not "stick with passwords" or "deal with lock-in", it's possible to get rid of the current problems and still end up with a system that's way more secure than traditional passwords.
This is good to bring up. Without vendor lock-in and attestation, passkeys have huge benefits for blocking phishing attacks. It's not "stick with passwords" or "deal with lock-in", it's possible to get rid of the current problems and still end up with a system that's way more secure than traditional passwords.
> No part of the specification requires Google, cloud or third party trust.
AFAIK the only reason you need Google, Apple, or etc. is because the mobile OS needs to make the process of doing the bluetooth pairing between a random device and the phone seamless. Given the crap networking we have in the world you need a 3rd party everyone can reach to exchange the most basic information. Then everything is local via Bluetooth.
> The point is replacing passwords with something which is equally user-friendly, but which cannot be phished.
Yes, and biometrics (which pretty much everyone uses) are great! They're device ONLY. It's entirely a convenience feature that avoids needing to enter the Required To Setup PIN/Passphrase every time.
AFAIK the only reason you need Google, Apple, or etc. is because the mobile OS needs to make the process of doing the bluetooth pairing between a random device and the phone seamless. Given the crap networking we have in the world you need a 3rd party everyone can reach to exchange the most basic information. Then everything is local via Bluetooth.
> The point is replacing passwords with something which is equally user-friendly, but which cannot be phished.
Yes, and biometrics (which pretty much everyone uses) are great! They're device ONLY. It's entirely a convenience feature that avoids needing to enter the Required To Setup PIN/Passphrase every time.
FIDO security keys don't store login-specific information. Passkeys do, which raises the lock-in problem.
To be clear, I want to be able to use passkeys, or something close, but I won't if I can't control my keys, and I can't if I can't use them cross-platform.
To be clear, I want to be able to use passkeys, or something close, but I won't if I can't control my keys, and I can't if I can't use them cross-platform.
Effectively, they really do (yes, the Relying Party technically stored the encrypted credential, but to the user, their keys really "are in the Yubikey" in any meaningful way).
But more importantly, they (to my knowledge) don’t offer any in-ecosystem-only backup/sync functionality, which would make switching vendors that much harder and thereby create platform/vendor lock-in.
But more importantly, they (to my knowledge) don’t offer any in-ecosystem-only backup/sync functionality, which would make switching vendors that much harder and thereby create platform/vendor lock-in.
Security key backup was always the biggest obstacle. In principle you could create fungible keys flashed with the same private key, but in practice that isn't possible (outside of some obscure open-source implementations).
The second obstacle, of course, is the question: why do I need a separate microcontroller taking up a USB slot, when the host device is capable of running the same software? Passkeys do solve that (though so would soft-FIDO without resident keys), but the bait comes with the hook of vendor lock-in.
The second obstacle, of course, is the question: why do I need a separate microcontroller taking up a USB slot, when the host device is capable of running the same software? Passkeys do solve that (though so would soft-FIDO without resident keys), but the bait comes with the hook of vendor lock-in.
> In principle you could create fungible keys flashed with the same private key, but in practice that isn't possible (outside of some obscure open-source implementations).
Not necessarily – Yubico has a proposal (that requires some changes to all RPs, though): https://www.yubico.com/blog/yubico-proposes-webauthn-protoco...
> why do I need a separate microcontroller taking up a USB slot, when the host device is capable of running the same software? Passkeys do solve that (though so would soft-FIDO without resident keys), but the bait comes with the hook of vendor lock-in.
Trusted computing and vendor neutrality are unfortunately somewhat at odds with each other. Google has learned that the hard way with Google Pay – only when they finally gave up on Secure Elements (in favor of HEE and software-based OS attestation) did it become available on non-Google devices. The device vendors and mobile carriers (which control the SIM, the only other pragmatic trusted hardware).
It would be amazing if there was a sort of "embeddable Yubikey" specification that would allow you to, logically or physically, install your own Secure Element/TPM and have that be decoupled from both OS and OEM, but it would be a major upstream effort.
Not necessarily – Yubico has a proposal (that requires some changes to all RPs, though): https://www.yubico.com/blog/yubico-proposes-webauthn-protoco...
> why do I need a separate microcontroller taking up a USB slot, when the host device is capable of running the same software? Passkeys do solve that (though so would soft-FIDO without resident keys), but the bait comes with the hook of vendor lock-in.
Trusted computing and vendor neutrality are unfortunately somewhat at odds with each other. Google has learned that the hard way with Google Pay – only when they finally gave up on Secure Elements (in favor of HEE and software-based OS attestation) did it become available on non-Google devices. The device vendors and mobile carriers (which control the SIM, the only other pragmatic trusted hardware).
It would be amazing if there was a sort of "embeddable Yubikey" specification that would allow you to, logically or physically, install your own Secure Element/TPM and have that be decoupled from both OS and OEM, but it would be a major upstream effort.
Current Yubikeys do allow you to store login information (Resident Keys in webauthn), and because Apple refuses to provide attestation for Passkeys, it's going to be very difficult for a website to force you to use a security key from any particular vendor.
Obviously Yubikeys (and most/all other hardware keys) do provide attestation, so in theory a website could refuse to let you register those -- but if that becomes common it would be easy for any company to create hardware keys which refuse attestation.
Obviously Yubikeys (and most/all other hardware keys) do provide attestation, so in theory a website could refuse to let you register those -- but if that becomes common it would be easy for any company to create hardware keys which refuse attestation.
Higher Yubikeys do, but other FIDO2 keys, including Yubico's ‘Security Key’ series, don't.
Apple's current policy on attestation is good (for consumers; I don't deny there are closed conditions where you'd legitimately use it), but their refusal to allow 3P integration is not.
Apple's current policy on attestation is good (for consumers; I don't deny there are closed conditions where you'd legitimately use it), but their refusal to allow 3P integration is not.
> 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.
I don't believe it's restricted to Yubikeys with biometrics:
https://support.google.com/accounts/answer/13548313
"You can create passkeys on these devices:
- A laptop or desktop that runs at least Windows 10 or macOS Ventura
- A mobile device that runs at least iOS 16 or Android 9
- A hardware security key that supports the FIDO2 protocol"
I don't believe it's restricted to Yubikeys with biometrics:
https://support.google.com/accounts/answer/13548313
"You can create passkeys on these devices:
- A laptop or desktop that runs at least Windows 10 or macOS Ventura
- A mobile device that runs at least iOS 16 or Android 9
- A hardware security key that supports the FIDO2 protocol"
Hearing “device+biometric” described as 2FA makes me chuckle. Really, that translates down to “biometrics reader storing the passkey+ biometric” being “2FA”. By that standard, “a device storing a way to verify the password + a keyboard to input the password” should be 2FA. In which case, passwords were always 2FA to begin with, since the server/OS acts as that device.
It seems to me that is the same problem as Single Sign On, and I think there simply needs to be legislation to make it not possible to monopolise markets this way (or just enforce the existing legislation on the topic).
WebAuthn/FIDO are not the issue here.
WebAuthn/FIDO are not the issue here.
I don’t necessarily think OP believes this point of view, but even HN folks seem to think passkey is some wild biometric stealing mega Corp conspiracy.
See a lot of the comments in this thread as an example: https://news.ycombinator.com/item?id=35801392
See a lot of the comments in this thread as an example: https://news.ycombinator.com/item?id=35801392
> HN folks seem to think passkey is some wild biometric stealing mega Corp conspiracy.
What it does is promotes further centralisation, because most users will use one of the big providers.
This wouldn’t be a problem either, except that the big providers are not accountable. Google, Meta, etc lock users’ accounts all the time. Users often have no recourse.
Passkeys will mean a locked Google account now impacts your ability to sign into all the sites where you used that passkey.
Think it can’t happen to you? “Oh Google won’t lock my account out!” That’s exactly what those locked out thought too.
The fundamental problem with Passkeys isn’t technical. Even ignoring the centralisation issue, the problem is a lack of organisational accountability on the part of Google, Meta etc.
And yeah, the tech industry, including the tech press, needs to own the fact that they’ve given these companies a free pass over this.
What it does is promotes further centralisation, because most users will use one of the big providers.
This wouldn’t be a problem either, except that the big providers are not accountable. Google, Meta, etc lock users’ accounts all the time. Users often have no recourse.
Passkeys will mean a locked Google account now impacts your ability to sign into all the sites where you used that passkey.
Think it can’t happen to you? “Oh Google won’t lock my account out!” That’s exactly what those locked out thought too.
The fundamental problem with Passkeys isn’t technical. Even ignoring the centralisation issue, the problem is a lack of organisational accountability on the part of Google, Meta etc.
And yeah, the tech industry, including the tech press, needs to own the fact that they’ve given these companies a free pass over this.
But I don't see how passkeys factor into this discussion at all. Yes, large companies are unaccountable and they do harmful things to their users without recourse. This is unrelated to the method you use to log into microsoft.com.
WebAuthn is not Single Sign On (where you are centralising logins) -- it seems a lot of people on HN think that it is. I don't like SSO as the only option for a site (precisely for the centralisation reasons), but that's very explicitly not what WebAuthn is. The test page for WebAuthn (on their site) is completely self-hosted and every site I've seen that supports WebAuthn self-hosts it.
WebAuthn is not Single Sign On (where you are centralising logins) -- it seems a lot of people on HN think that it is. I don't like SSO as the only option for a site (precisely for the centralisation reasons), but that's very explicitly not what WebAuthn is. The test page for WebAuthn (on their site) is completely self-hosted and every site I've seen that supports WebAuthn self-hosts it.
The parent comment I replied to brought up passkeys, trying to paint criticism of it as “conspiracy”.
Is "passkey" not another word for a WebAuthn/FIDO token?
They’re similar but differ in some important ways[1].
Passkeys were built on top of work done by FIDO though.
[1] https://css-tricks.com/passkeys-what-the-heck-and-why/#the-d...
Passkeys were built on top of work done by FIDO though.
[1] https://css-tricks.com/passkeys-what-the-heck-and-why/#the-d...
[deleted]
Just to be clear, because I do t know the answer to this… if Google locks your account, can you still use your Android device to login with a passkey to that other site?
I guess that'll depend on whether you phone still functions if Google dlocks your account.
But worst case, yes, but only in the same way that if you put all your photos on Google photos and then they block your account, you won't have access to your photos any more.
If that's a concern, then don't do that.
I think the passkey design actively encourages sites to support multiple authenticators, so you just enrol your yubikey as well as your phone and you're good.
But worst case, yes, but only in the same way that if you put all your photos on Google photos and then they block your account, you won't have access to your photos any more.
If that's a concern, then don't do that.
I think the passkey design actively encourages sites to support multiple authenticators, so you just enrol your yubikey as well as your phone and you're good.
So what I hear you saying is that if a normal person gets locked out of their Google account, they will also be locked out of every other website they have accounts with.
Yikes. I guess I’ll be telling everybody to stay far away from passkeys.
*By “normal,” I mean the people who don’t have yubikeys, like myself. Lol.
Edit: wait, what do you mean if your phone still works? Also, does this mean if you lose your phone you can’t log into anything? How do you recover from that?
Yikes. I guess I’ll be telling everybody to stay far away from passkeys.
*By “normal,” I mean the people who don’t have yubikeys, like myself. Lol.
Edit: wait, what do you mean if your phone still works? Also, does this mean if you lose your phone you can’t log into anything? How do you recover from that?
> So what I hear you saying is that if a normal person gets locked out of their Google account, they will also be locked out of every other website they have accounts with.
> Yikes. I guess I’ll be telling everybody to stay far away from passkeys.
This is a bit like telling everyone to stay away from password managers, just because Google offers one with Chrome that potentially disappears (taking all your passwords with it) when they nuke your account.
No, passkeys are fine. Just don't rely on a single, central provider who you consider an adversary.
> Edit: wait, what do you mean if your phone still works? Also, does this mean if you lose your phone you can’t log into anything? How do you recover from that?
If you lose your yubikey/Google authenticator/whatever TOTP, you're in a similar pickle. So then you do account recovery (recovery codes etc.)
> Yikes. I guess I’ll be telling everybody to stay far away from passkeys.
This is a bit like telling everyone to stay away from password managers, just because Google offers one with Chrome that potentially disappears (taking all your passwords with it) when they nuke your account.
No, passkeys are fine. Just don't rely on a single, central provider who you consider an adversary.
> Edit: wait, what do you mean if your phone still works? Also, does this mean if you lose your phone you can’t log into anything? How do you recover from that?
If you lose your yubikey/Google authenticator/whatever TOTP, you're in a similar pickle. So then you do account recovery (recovery codes etc.)
> Also, does this mean if you lose your phone you can’t log into anything? How do you recover from that?
If your passkey is tied to the phone (which will be true for most people), losing your phone will be an interesting experience.
Assuming you remember your Google account password, you will have to buy a new phone.
In many cases you’ll need a new SIM or eSIM as well, eg if you have SMS based 2FA enabled. If you use Google Authenticator, your phone’s gone, so you better have a fallback — either SMS or fallback 2FA codes.
If you need a SIM, and used Passkeys to login to your telco’s online account … um, tough. You’d better call customer support.
Essentially, passkeys tied to one device is a house of cards. When things go wrong (eg you lose your phone or your dog chews your Yubikey) it’s not pretty. But of course security pros know this, they have backups and spend time securing and testing the backups.
Most ordinary users won’t, of course.
More interesting is the underlying assumption that your Google account works. If your stolen phone was used to do something shady or simply something Google’s account protection systems don’t like, your account may be locked out. At which point things get even more interesting.
That said — cross platform Passkeys should exist soon.
1Password is implementing Passkey support[1], hopefully KeePassXC will do it too, then users of those apps will be okay. But I’ve no idea how easy it’ll be to move keys around.
The spec really needs to support interop better, with formal import/export support. You shouldn’t be able to say you support PassKeys if you don’t support import/export.
But of course even then, most users won’t export or back up their keys ¯\_(ツ)_/¯
[1] https://www.future.1password.com/passkeys/
If your passkey is tied to the phone (which will be true for most people), losing your phone will be an interesting experience.
Assuming you remember your Google account password, you will have to buy a new phone.
In many cases you’ll need a new SIM or eSIM as well, eg if you have SMS based 2FA enabled. If you use Google Authenticator, your phone’s gone, so you better have a fallback — either SMS or fallback 2FA codes.
If you need a SIM, and used Passkeys to login to your telco’s online account … um, tough. You’d better call customer support.
Essentially, passkeys tied to one device is a house of cards. When things go wrong (eg you lose your phone or your dog chews your Yubikey) it’s not pretty. But of course security pros know this, they have backups and spend time securing and testing the backups.
Most ordinary users won’t, of course.
More interesting is the underlying assumption that your Google account works. If your stolen phone was used to do something shady or simply something Google’s account protection systems don’t like, your account may be locked out. At which point things get even more interesting.
That said — cross platform Passkeys should exist soon.
1Password is implementing Passkey support[1], hopefully KeePassXC will do it too, then users of those apps will be okay. But I’ve no idea how easy it’ll be to move keys around.
The spec really needs to support interop better, with formal import/export support. You shouldn’t be able to say you support PassKeys if you don’t support import/export.
But of course even then, most users won’t export or back up their keys ¯\_(ツ)_/¯
[1] https://www.future.1password.com/passkeys/
> [1] https://www.future.1password.com/passkeys/
Worth noting is that this is desktop only (and arrives June 6). They are not supporting passkeys on their mobile apps yet, and AFAIK there is no timeline announced for when that will happen.
Worth noting is that this is desktop only (and arrives June 6). They are not supporting passkeys on their mobile apps yet, and AFAIK there is no timeline announced for when that will happen.
> What it does is promotes further centralisation, because most users will use one of the big providers.
Because there are no easy non-centralised solutions (that works for Average Joe)?
Remember
Average Joe cannot
- backup keepass
- 3-2-1 backups using ZFS
BTW, if so many average Joe's lost google accounts then there would be outrage and great chaos (like ticketmaster etc). So some people lost Google accounts - true. Same some people list U2F key.
> the tech industry, including the tech press, n
Pragmatism will win.
This reminds me of IRC vs WhatsApp (or Signal). People want things to be simple.
Because there are no easy non-centralised solutions (that works for Average Joe)?
Remember
Average Joe cannot
- backup keepass
- 3-2-1 backups using ZFS
BTW, if so many average Joe's lost google accounts then there would be outrage and great chaos (like ticketmaster etc). So some people lost Google accounts - true. Same some people list U2F key.
> the tech industry, including the tech press, n
Pragmatism will win.
This reminds me of IRC vs WhatsApp (or Signal). People want things to be simple.
> People want things to be simple.
As a reminder, if you ask what the best way is to back up a Yubikey, the advice is:
- Buy a second Yubikey
- Store it in a separate physical location, preferably within a fireproof safe
- Whenever you make a new account, set yourself a reminder to go get your second Yubikey, log in with the first Yubikey and then go through whatever process the site has (on a site-by-site basis without a consistent UI) and add the second Yubikey as another credential.
- Then go back to whatever secondary location you've chosen and put the second Yubikey back.
- And then repeat that process every single time you make a new account.
In contrast, dragging a KeePassXC vault into a Dropbox folder one time and just leaving it there and using it from Dropbox is incredibly simple and I feel like pretty much anyone is capable of doing that.
As a reminder, if you ask what the best way is to back up a Yubikey, the advice is:
- Buy a second Yubikey
- Store it in a separate physical location, preferably within a fireproof safe
- Whenever you make a new account, set yourself a reminder to go get your second Yubikey, log in with the first Yubikey and then go through whatever process the site has (on a site-by-site basis without a consistent UI) and add the second Yubikey as another credential.
- Then go back to whatever secondary location you've chosen and put the second Yubikey back.
- And then repeat that process every single time you make a new account.
In contrast, dragging a KeePassXC vault into a Dropbox folder one time and just leaving it there and using it from Dropbox is incredibly simple and I feel like pretty much anyone is capable of doing that.
If you don't need a proper second factor, just set up TOTP and store it in KeePassXC. There is little benefit to a WebAuthn/FIFO "key" stored in your password manager over a password manager with your TOTP stored in it -- almost all of the benefits of WebAuthn (making phishing much harder) already exist with password managers that auto-fill.
There are usecases where you need proper multi-factor authentication, and in those cases you are either a professional (meaning you can handle backups yourself) or you're working for a large company where the management of the keys is done by IT and normal workers don't have to care about it.
There are usecases where you need proper multi-factor authentication, and in those cases you are either a professional (meaning you can handle backups yourself) or you're working for a large company where the management of the keys is done by IT and normal workers don't have to care about it.
I disagree that a proper key-based solution wouldn't have security benefits (auto-fill doesn't always work and is more vulnerable to phishing).
But I also really want to be clear here that we are not talking about multi-factor authentication in the long run. The explicit goal of Google/Microsoft/Apple is to get rid of passwords. Passkey is designed as a replacement for passwords. It's not a replacement right now, but that is the intention, they are not thinking about having a Yubikey as a second-factor for login.
But I also really want to be clear here that we are not talking about multi-factor authentication in the long run. The explicit goal of Google/Microsoft/Apple is to get rid of passwords. Passkey is designed as a replacement for passwords. It's not a replacement right now, but that is the intention, they are not thinking about having a Yubikey as a second-factor for login.
When I said "auto-fill", I was referring to auto-fill with a browser extension where the website is checked. Yes, the FIDO method is even nicer from a technical perspective, but from a security perspective they are similar.
But of course, you can be phished into copying your password into a phishing site. So there are benefits, but it's not a huge difference in this one specific context (no physical token, using a password manager with a browser-extension-based auto-fill).
But of course, you can be phished into copying your password into a phishing site. So there are benefits, but it's not a huge difference in this one specific context (no physical token, using a password manager with a browser-extension-based auto-fill).
You are lucky if you find a mum with 3 kids or cafe owner or a fruit seller using TOTP in keepassXC. Do you know they would prefer a phone (not laptop/desktop)? They dont have laptop.
The HN article we are commenting on is about a PR to add a feature to KeePassXC.
> Buy a second Yubikey
I can (as a geek) but this is a problem for average Joe or a single mum with 2 kids.
This is the reason even banks or <your employer> incl. Federal places uses Cisco DUO not an opensource solution.
Most things are for average customer. passkeys are great
- Assuming a person keeps one password (either Apple or Google OK)
- Phishing for them is reduced
- No need to squeeze brain for was it username or email address (for login field)
- Most phones have fingerprint (even < $60 in developing world too with Android)
- Passkeys work from Android 9 onwards
- At the end some one needs to compromise.
I can (as a geek) but this is a problem for average Joe or a single mum with 2 kids.
This is the reason even banks or <your employer> incl. Federal places uses Cisco DUO not an opensource solution.
Most things are for average customer. passkeys are great
- Assuming a person keeps one password (either Apple or Google OK)
- Phishing for them is reduced
- No need to squeeze brain for was it username or email address (for login field)
- Most phones have fingerprint (even < $60 in developing world too with Android)
- Passkeys work from Android 9 onwards
- At the end some one needs to compromise.
- And they can't move ecosystems.
- And logging into your bank requires a proprietary device.
Let's be clear about what we're "compromising" about. If passkeys are going to be a replacement for passwords (and Google/Microsoft/Apple are very up-front about the fact that they want passkeys to be a replacement for passwords) they have to handle all of the use cases. But even if that wasn't the case and they could just target the general consumer, the downsides here are not just for techy people. The platform lock-in will absolutely affect ordinary people as well.
It'll mean that when your family member that doesn't know to make backups loses their iPhone, the only way to get those keys back will be to buy another iPhone.
- And logging into your bank requires a proprietary device.
Let's be clear about what we're "compromising" about. If passkeys are going to be a replacement for passwords (and Google/Microsoft/Apple are very up-front about the fact that they want passkeys to be a replacement for passwords) they have to handle all of the use cases. But even if that wasn't the case and they could just target the general consumer, the downsides here are not just for techy people. The platform lock-in will absolutely affect ordinary people as well.
It'll mean that when your family member that doesn't know to make backups loses their iPhone, the only way to get those keys back will be to buy another iPhone.
> ecosystems
A majority don't. A majority use their phones/banks rather than analysing ecosystems.
> It'll mean that when your family member that doesn't know to make backups loses their iPhone, the only way to get those keys back will be to buy another iPhone.
That is acceptable solution. Buy and then move on with life. Everything will be back after your shell out $$ (android).
But with local will the family member send the hard disk or USB disk containing keys to recovery? Which recovery company? Will they be honest?
Whereas if you want to new phone - all works then easy.
People want simplicity. Really thats it.
(Again it may be sad for those that don't want to carry phone but the world is designed for average user).
BTW, why do you thing banks are using proprietary device.
Ask the HN -er to
- make it possible using U2F or TOTP keys (QR code)
- the same HN-user likes to implement flashy APP - so that they
- track, help whatever
A majority don't. A majority use their phones/banks rather than analysing ecosystems.
> It'll mean that when your family member that doesn't know to make backups loses their iPhone, the only way to get those keys back will be to buy another iPhone.
That is acceptable solution. Buy and then move on with life. Everything will be back after your shell out $$ (android).
But with local will the family member send the hard disk or USB disk containing keys to recovery? Which recovery company? Will they be honest?
Whereas if you want to new phone - all works then easy.
People want simplicity. Really thats it.
(Again it may be sad for those that don't want to carry phone but the world is designed for average user).
BTW, why do you thing banks are using proprietary device.
Ask the HN -er to
- make it possible using U2F or TOTP keys (QR code)
- the same HN-user likes to implement flashy APP - so that they
- track, help whatever
> A majority don't. A majority use their phones/banks rather than analysing ecosystems.
Is this intended to be an argument for my point or against it?
The majority of people don't think about platform lock-in until it bites them, and money is tight and they can't afford to get an iPhone and then they sigh and buy one anyway because it's too annoying to switch.
> That is acceptable solution. Buy and then move on with life.
Like, you are laying out exactly how vendor lock-in happens, but your point seems to be that vendor lock-in is fine and we should just stop talking about it. "Yes, passkeys are vendor lock-in and I don't care" is maybe not as strong of an argument as you think it is? People like to be able to choose which phone they're going to buy.
----
> But with local will the family member send the hard disk or USB disk containing keys to recovery
No. They'll use Bitwarden or Dropbox and it'll be fine -- easier than setting up a new phone. They won't need to wonder if their new phone is compatible with anything, they won't need to wonder about whether their computer will work or not. It'll just work, immediately, as soon as their password app is installed.
Literally every single restoration/syncing option that's available for passkeys is also available for password databases, just as simple if not simpler. But you get an addition of a number of other simple solutions like:
- if you lose your phone and show up to a friend's house, you can type a password into a web browser and get all of your passwords back instantly.
- if you buy a windows computer and you have all of your passwords on an iPhone, you type a password into a web browser or an app and get all of your passwords back instantly.
None of that is supported with passkey.
Vendor lock-in does not make people's lives easier, it makes things more complicated. Do people really think that passkey is easier to back up than Bitwarden is?
Is this intended to be an argument for my point or against it?
The majority of people don't think about platform lock-in until it bites them, and money is tight and they can't afford to get an iPhone and then they sigh and buy one anyway because it's too annoying to switch.
> That is acceptable solution. Buy and then move on with life.
Like, you are laying out exactly how vendor lock-in happens, but your point seems to be that vendor lock-in is fine and we should just stop talking about it. "Yes, passkeys are vendor lock-in and I don't care" is maybe not as strong of an argument as you think it is? People like to be able to choose which phone they're going to buy.
----
> But with local will the family member send the hard disk or USB disk containing keys to recovery
No. They'll use Bitwarden or Dropbox and it'll be fine -- easier than setting up a new phone. They won't need to wonder if their new phone is compatible with anything, they won't need to wonder about whether their computer will work or not. It'll just work, immediately, as soon as their password app is installed.
Literally every single restoration/syncing option that's available for passkeys is also available for password databases, just as simple if not simpler. But you get an addition of a number of other simple solutions like:
- if you lose your phone and show up to a friend's house, you can type a password into a web browser and get all of your passwords back instantly.
- if you buy a windows computer and you have all of your passwords on an iPhone, you type a password into a web browser or an app and get all of your passwords back instantly.
None of that is supported with passkey.
Vendor lock-in does not make people's lives easier, it makes things more complicated. Do people really think that passkey is easier to back up than Bitwarden is?
I understand your argument from a philosphical or idealistic view. You are correct
People know Google/FAANG rather than bitwarden.
If your family knows bitwarden then kudos. I am living in a different world.
> Like, you are laying out exactly how vendor lock-in happens, but your point seems to be that vendor lock-in is fine and we should just stop talking about it. "
- We can talk about it
- And we are now.
- But people in power don't understand (or care).
There are no equivalent, easy option. I wish some company like proton mail or some one else would run a phone with all equivalent google services. But they don't.
> They'll use Bitwarden or Dropbox and it'll be fine -- easier than setting up a new phone.
Are you sure? People would ideally like
- Buy phone
- sign in google/apple account
- All apps installed and ready to consume/produce MEDIA
> Do people really think that passkey is easier to back up than Bitwarden is?
People think in different way. They know 2 things
- Google/Apple username + password
- get SMS recovery info (again I am not recommending - people are simplistic). May be you can replace this with some other option
- For example, facebook allows for nominating a friend or a facebook for recovery
- Enter the code
- ready to consume/produce MEDIA
> They won't need to wonder if their new phone is compatible with anything,
Average Joe has brand loyalty so that they will stay in whatever. Usually. If one goes to Samsung, they usually stay there - even if Pixel is better.
> They'll use Bitwarden or Dropbox and it'll be fine -- easier than setting up a new phone.
Where is the 2FA for dropbox or bitwarden? is that file supposed to be accessible without 2FA?
I agree to your no-vendor lockin sentiment but this means some one should invest and build a platform neutral + verifiable thing.
And even if some decent govt steps in people will claim it is all to track you. So EOF.
People know Google/FAANG rather than bitwarden.
If your family knows bitwarden then kudos. I am living in a different world.
> Like, you are laying out exactly how vendor lock-in happens, but your point seems to be that vendor lock-in is fine and we should just stop talking about it. "
- We can talk about it
- And we are now.
- But people in power don't understand (or care).
There are no equivalent, easy option. I wish some company like proton mail or some one else would run a phone with all equivalent google services. But they don't.
> They'll use Bitwarden or Dropbox and it'll be fine -- easier than setting up a new phone.
Are you sure? People would ideally like
- Buy phone
- sign in google/apple account
- All apps installed and ready to consume/produce MEDIA
> Do people really think that passkey is easier to back up than Bitwarden is?
People think in different way. They know 2 things
- Google/Apple username + password
- get SMS recovery info (again I am not recommending - people are simplistic). May be you can replace this with some other option
- For example, facebook allows for nominating a friend or a facebook for recovery
- Enter the code
- ready to consume/produce MEDIA
> They won't need to wonder if their new phone is compatible with anything,
Average Joe has brand loyalty so that they will stay in whatever. Usually. If one goes to Samsung, they usually stay there - even if Pixel is better.
> They'll use Bitwarden or Dropbox and it'll be fine -- easier than setting up a new phone.
Where is the 2FA for dropbox or bitwarden? is that file supposed to be accessible without 2FA?
I agree to your no-vendor lockin sentiment but this means some one should invest and build a platform neutral + verifiable thing.
And even if some decent govt steps in people will claim it is all to track you. So EOF.
> There are no equivalent, easy option
Of course there is, the equivalent easy option is passkeys without vendor lock-in. Vendor lock-in does not make any of this easier or simpler.
Also note that current platform-offered password managers already allow syncing to new devices, so even for the people who are saying "I only want to use my Google account", syncing passwords through their Google account to Android is just as easy as using passkeys would be.
> Average Joe has brand loyalty so that they will stay in whatever. Usually. If one goes to Samsung, they usually stay there - even if Pixel is better.
This is just not true. I see people switch ecosystems all the time, and when they refuse to switch ecosystems, the reason they usually give is "it would be too annoying to port everything." Lock-in is something that affects ordinary people, I see this all the time.
> Where is the 2FA for dropbox or bitwarden? is that file supposed to be accessible without 2FA?
Weren't you just arguing for simplicity? The average user doesn't use 2FA. They should, but they don't because it's too complicated for them.
----
But this is silly, we've graduated from "people need a simple solution" to "any solution that involves anything other than a Google or iCloud account doesn't count as simple."
Which, sure, if your definition of simple is literally "the passwords stay in your Google account" then only putting keys in a Google account will do. But it's a pretty tautological definition.
And also a definition that doesn't hold up for ordinary users in my experience. People do actually understand that there are passwords for services other than Google and Microsoft because they interact with those systems today just fine. Pretty provably they can handle that level of complexity because that level of complexity is embedded in every single service that we use today.
But let's assume you're right. Even under that criteria, even if your definition of simplicity is "I sign in with an Apple/Google password and that's it, and it has to be specifically an Apple/Google password -- I want to re-emphasize that current password vaults with Google/Apple already handle this use case fine today just as simply as passkeys do, so there's still no extra simplicity or ease-of-use with passkey synchronization. At best, for those users it's as easy to sync a passkey as it would be to use a password manager. But password sync to new phones on log-in is already supported natively if you use the native built-in password managers (ie, the same password managers you'd be using for passkey).
Even under the most restrictive criteria with the least possible number of steps for syncing -- password vaults can be synced just as easily if not easier than passkeys can be.
Of course there is, the equivalent easy option is passkeys without vendor lock-in. Vendor lock-in does not make any of this easier or simpler.
Also note that current platform-offered password managers already allow syncing to new devices, so even for the people who are saying "I only want to use my Google account", syncing passwords through their Google account to Android is just as easy as using passkeys would be.
> Average Joe has brand loyalty so that they will stay in whatever. Usually. If one goes to Samsung, they usually stay there - even if Pixel is better.
This is just not true. I see people switch ecosystems all the time, and when they refuse to switch ecosystems, the reason they usually give is "it would be too annoying to port everything." Lock-in is something that affects ordinary people, I see this all the time.
> Where is the 2FA for dropbox or bitwarden? is that file supposed to be accessible without 2FA?
Weren't you just arguing for simplicity? The average user doesn't use 2FA. They should, but they don't because it's too complicated for them.
----
But this is silly, we've graduated from "people need a simple solution" to "any solution that involves anything other than a Google or iCloud account doesn't count as simple."
Which, sure, if your definition of simple is literally "the passwords stay in your Google account" then only putting keys in a Google account will do. But it's a pretty tautological definition.
And also a definition that doesn't hold up for ordinary users in my experience. People do actually understand that there are passwords for services other than Google and Microsoft because they interact with those systems today just fine. Pretty provably they can handle that level of complexity because that level of complexity is embedded in every single service that we use today.
But let's assume you're right. Even under that criteria, even if your definition of simplicity is "I sign in with an Apple/Google password and that's it, and it has to be specifically an Apple/Google password -- I want to re-emphasize that current password vaults with Google/Apple already handle this use case fine today just as simply as passkeys do, so there's still no extra simplicity or ease-of-use with passkey synchronization. At best, for those users it's as easy to sync a passkey as it would be to use a password manager. But password sync to new phones on log-in is already supported natively if you use the native built-in password managers (ie, the same password managers you'd be using for passkey).
Even under the most restrictive criteria with the least possible number of steps for syncing -- password vaults can be synced just as easily if not easier than passkeys can be.
If they buy another iPhone, how do they authenticate to the cloud account? A password that hasn’t been used in months or years? Standard credit collection agency data (which is stealable and has been stolen for many people already?)
Yes, correct. Apple documents its restore process here:
- https://support.apple.com/en-us/HT210217
- https://support.apple.com/en-us/HT204974
They also have account recovery processes which use metadata about you to try and verify your identity.
Note, this is the system they are using today for passkeys. So this is not some kind of compromise or complexity with password vaults that passkeys eliminate, it's just the universal process of account recovery that we have today with all of its flaws, and passkeys don't add any additional protections or simplicity on top of this system.
- https://support.apple.com/en-us/HT210217
- https://support.apple.com/en-us/HT204974
They also have account recovery processes which use metadata about you to try and verify your identity.
Note, this is the system they are using today for passkeys. So this is not some kind of compromise or complexity with password vaults that passkeys eliminate, it's just the universal process of account recovery that we have today with all of its flaws, and passkeys don't add any additional protections or simplicity on top of this system.
> At the end some one needs to compromise
Sure. Google and Meta and similar companies can compromise by having proper redressal processes which will hold up in court, should they lock your account.
Being an identity provider who can take away your identity with no legal recourse is not legally tenable and will be challenged legally.
If you’re an engineer working on this, expect to get beat up by the EU on this, to start with. There is a solution though — build import & export into the spec and actually implement it well.
Google actually has done a decent job with Google Takeout. It’s worth learning from.
Sure. Google and Meta and similar companies can compromise by having proper redressal processes which will hold up in court, should they lock your account.
Being an identity provider who can take away your identity with no legal recourse is not legally tenable and will be challenged legally.
If you’re an engineer working on this, expect to get beat up by the EU on this, to start with. There is a solution though — build import & export into the spec and actually implement it well.
Google actually has done a decent job with Google Takeout. It’s worth learning from.
The US Federal Government got rid of passwords in 2004. They use smart cards issued by approved issuers. They are certificate-based, so if you lose your card another one can be issued to you with the same properties on the certificate. Additionally, they usually escrow the Email Certificate private key.
I maintain some open source middleware for these cards [0].
[0] https://cackey.rkeene.org/
I maintain some open source middleware for these cards [0].
[0] https://cackey.rkeene.org/
Having worked with the Federal government you are woefully misinformed. There likely is a policy statement announcing that passwords are being phased out, but I can assure they were alive and well past 2004.
There was a Presidential Directive signed by George W. Bush in August of 2004 [0] that resulted in follow-up actions by every department of the executive branch of the US Government, the creation of the physical infrastructure, annual reports on compliance.
As someone who has worked with the DOD OCIO on this, I am likely significantly more informed than you and the assertion to the contrary is unfounded and likely incorrect.
https://www.dhs.gov/homeland-security-presidential-directive...
As someone who has worked with the DOD OCIO on this, I am likely significantly more informed than you and the assertion to the contrary is unfounded and likely incorrect.
https://www.dhs.gov/homeland-security-presidential-directive...
The word 'password' does not even appear in the document you linked.
... do you think that's the only way it applies ? Did you read it ?
It says that no other method of authentication to US Government (exempting specifically national security systems) except for the approved method may be used. Since there are no passwords in the list of strong authenticators, it's not permitted.
Here are the relevant sections pieced together so you can't miss it:
Note "Mandatory"
> establishing a mandatory, Government-wide standard for secure and > reliable forms of identification issued by the Federal Government > to its employees and contractors (including contractor employees)
Note that the definition of the phrase used above excludes passwords:
> "Secure and reliable forms of identification" for purposes of this > directive means identification that (a) ...; (b) is strongly resistant > to identity fraud, tampering, counterfeiting, and terrorist exploitation;
This is the part that says they have 8 months after the August publication of HSPD-12 to comply with the above, and specifically for US Government computers (called Information Systems).
> As promptly as possible, but in no case later than 8 months after the > date of promulgation of the Standard, the heads of executive departments > and agencies shall, to the maximum extent practicable, require the use > of identification by Federal employees and contractors that meets the Standard > in gaining [...] logical access to Federally controlled information systems. > Departments and agencies shall implement this directive in a manner > consistent with ongoing Government-wide activities, policies and > guidance issued by OMB, which shall ensure compliance.
So, upon... actually reading HSPD-12 there's no interpretation that can be made where passwords are permitted to access unclassified systems... aka, my original statement.
You are wrong.
It says that no other method of authentication to US Government (exempting specifically national security systems) except for the approved method may be used. Since there are no passwords in the list of strong authenticators, it's not permitted.
Here are the relevant sections pieced together so you can't miss it:
Note "Mandatory"
> establishing a mandatory, Government-wide standard for secure and > reliable forms of identification issued by the Federal Government > to its employees and contractors (including contractor employees)
Note that the definition of the phrase used above excludes passwords:
> "Secure and reliable forms of identification" for purposes of this > directive means identification that (a) ...; (b) is strongly resistant > to identity fraud, tampering, counterfeiting, and terrorist exploitation;
This is the part that says they have 8 months after the August publication of HSPD-12 to comply with the above, and specifically for US Government computers (called Information Systems).
> As promptly as possible, but in no case later than 8 months after the > date of promulgation of the Standard, the heads of executive departments > and agencies shall, to the maximum extent practicable, require the use > of identification by Federal employees and contractors that meets the Standard > in gaining [...] logical access to Federally controlled information systems. > Departments and agencies shall implement this directive in a manner > consistent with ongoing Government-wide activities, policies and > guidance issued by OMB, which shall ensure compliance.
So, upon... actually reading HSPD-12 there's no interpretation that can be made where passwords are permitted to access unclassified systems... aka, my original statement.
You are wrong.
> BTW, if so many average Joe's lost google accounts then there would be outrage and great chaos (like ticketmaster etc). So some people lost Google accounts - true. Same some people list U2F key.
They don’t “lose” Google accounts or Meta accounts or whatever. They’re locked out. In many cases, it appears lockouts can be triggered even by external events, including bad actors. Most companies are famously opaque on how lockouts happen, but there’s enough affected users out there to start forming some hypotheses.
Your argument is that the failure rate is so small, it doesn’t matter. “We’ll worry about it when the failure rate increases.”
This is what lack of accountability looks like, because you’re completely oblivious to the human consequences of even one failure.
Organisationally, companies like Google or Meta want billions of users, and want to manage the keys to their users’ digital universe, but don’t want to put in decent redressal processes for when things go wrong.
It’s not a tenable situation. Either the public will need to reevaluate how much they can trust big providers, or big providers might find legislation or legal action directing them to do better.
They don’t “lose” Google accounts or Meta accounts or whatever. They’re locked out. In many cases, it appears lockouts can be triggered even by external events, including bad actors. Most companies are famously opaque on how lockouts happen, but there’s enough affected users out there to start forming some hypotheses.
Your argument is that the failure rate is so small, it doesn’t matter. “We’ll worry about it when the failure rate increases.”
This is what lack of accountability looks like, because you’re completely oblivious to the human consequences of even one failure.
Organisationally, companies like Google or Meta want billions of users, and want to manage the keys to their users’ digital universe, but don’t want to put in decent redressal processes for when things go wrong.
It’s not a tenable situation. Either the public will need to reevaluate how much they can trust big providers, or big providers might find legislation or legal action directing them to do better.
Ticketmaster outrage has exactly the same effect as complaints against Google.
Average Joe has no idea whatsoever how to complain and get noticed. That's like saying "If shoplifting were so common there would be police in every store." Nope, it's just the cost of doing business.
Cloud backup works for average users. That includes keypass. Heck, even HN users do it that way. The only difference is that we have 16 word DiceWare passwords and key files on YubiKey devices.
The scariest problem to me isn't centralization, it's a lack of recourse when things go wrong.
Average Joe has no idea whatsoever how to complain and get noticed. That's like saying "If shoplifting were so common there would be police in every store." Nope, it's just the cost of doing business.
Cloud backup works for average users. That includes keypass. Heck, even HN users do it that way. The only difference is that we have 16 word DiceWare passwords and key files on YubiKey devices.
The scariest problem to me isn't centralization, it's a lack of recourse when things go wrong.
> tcketmaster
IIRC, nothing changed.
Take for example practices of PayPal or VISA etc. Nothing changed.
> Cloud backup works for average users. That includes keypass. Heck, even HN users do it that way. The only difference is that we have 16 word DiceWare passwords and key files on YubiKey devices.
Sorry most HN users are the ones building closed systems.
Sure, they work in FAANG for 10 years - get enough $$$M then sure complain things are NOT open.
> it's a lack of recourse when things go wrong.
but does it happen outside of banking etc. Most average Joe does not keep 10 year old email like a geek. They keep moving on.
I am a 20 year veteran of linux user. Sadly and frustratingly
- There is no easy open solution for google drive or docs
- Dont ask average Joe to do hosting/nextcloud etc
- I wish some one like FSF, Linux foundatation built some products that are usable (like firefox phone). Even during firefox phone sales, I found most of the EU devs were using for their daily use iPhone or expensive Samsung Galaxy. It is ridiculous to tell others to use 512MB or 1GB firefox phone when they used state of art
- Even recently I wanted to implement something like Codeberg at a large University. No help from their side.
IIRC, nothing changed.
Take for example practices of PayPal or VISA etc. Nothing changed.
> Cloud backup works for average users. That includes keypass. Heck, even HN users do it that way. The only difference is that we have 16 word DiceWare passwords and key files on YubiKey devices.
Sorry most HN users are the ones building closed systems.
Sure, they work in FAANG for 10 years - get enough $$$M then sure complain things are NOT open.
> it's a lack of recourse when things go wrong.
but does it happen outside of banking etc. Most average Joe does not keep 10 year old email like a geek. They keep moving on.
I am a 20 year veteran of linux user. Sadly and frustratingly
- There is no easy open solution for google drive or docs
- Dont ask average Joe to do hosting/nextcloud etc
- I wish some one like FSF, Linux foundatation built some products that are usable (like firefox phone). Even during firefox phone sales, I found most of the EU devs were using for their daily use iPhone or expensive Samsung Galaxy. It is ridiculous to tell others to use 512MB or 1GB firefox phone when they used state of art
- Even recently I wanted to implement something like Codeberg at a large University. No help from their side.
I don't have an issue with simple hardware devices being used but for me that's overkill. And means I always need that device with me, and hope it doesn't break, or get lost or stolen. The only way to avoid these issues is to have multiple devices.
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.
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.
That's a lot of speculation to be using as the basis for opinion.
Why would they bother trying to track you through a specification which is specifically designed to make it hard to track users? If you're using one of these software-based SSO lock-in "tokens" then they can get all the information they want from telemetry (nee spyware) on the device.
A device you must use to authenticate.
> are none are "multinational corps" in the derogative sense
YET. Remember when LastPass was the second coming liberating us from the devils of Google passwords?
YET. Remember when LastPass was the second coming liberating us from the devils of Google passwords?
The vendor locking argument is less about "classical" WebAuthn and more about passkeys.
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.
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.
Absolutely, this is the one reason I'm not interested in passkeys yet. I want to fully own my authentication keys myself. Not trusting Google or Microsoft for that.
I hope it comes to zx2c4 pass too <3
I hope it comes to zx2c4 pass too <3
I don't understand which part of FIDO/WebAuthn requires "trusting Google or Microsoft"?
The part where they are the sole implementors of the spec.
What do you mean? I run Keycloak for my home lab authentication needs and can use my YubiKey as a Webauthn factor from Firefox running on my Linux PC.
The only part where MS comes into the picture is the "Microsoft Windows" sticker on the bottom of the laptop, since HP shipped windows pre-installed.
The only part where MS comes into the picture is the "Microsoft Windows" sticker on the bottom of the laptop, since HP shipped windows pre-installed.
Even forcing people to buy yubikeys is an antipattern.
We shouldn’t be forced to spend money at any company. Where are the Free (beer and Libre) methods??
We shouldn’t be forced to spend money at any company. Where are the Free (beer and Libre) methods??
There was a kinda-free option (as in you had to have an iPhone, but the app itself was free). Krypt.co had this based on the iphone's secure enclave. It was bought by Akamai, and it's not clear what state it's in.
https://krypt.co/
I think there was also an implementation for mac os based on the t1/t2 chip, but since I've never had such a mac, I've never looked properly into that. But that probably means that you could roll your own.
A quick google search yields this for Linux with a TPM: https://github.com/psanford/tpm-fido
https://krypt.co/
I think there was also an implementation for mac os based on the t1/t2 chip, but since I've never had such a mac, I've never looked properly into that. But that probably means that you could roll your own.
A quick google search yields this for Linux with a TPM: https://github.com/psanford/tpm-fido
Nitrokey has a free software implementation of their firmware.
But ultimately you need to get some hardware _somehow_ which costs money, though some conferences give out free Yubikeys (or equivalent) and most enterprises would provide them to users directly.
But ultimately you need to get some hardware _somehow_ which costs money, though some conferences give out free Yubikeys (or equivalent) and most enterprises would provide them to users directly.
It is a very large and complex standard that further centralizes authentication in the hands of several megacorps. The previous OpenID attempt was a resounding success, and this is a logical continuation. Google and co want to know where you log in to serve you "better" ads.
The countermeasure remains the same - create an isolated account on each new website/service you use.
But you can use FIDO without ever touching MS/Google. For example, Codeberg (code hosting based on some soft-fork of Gitea) supports this with local-accounts.
What you are describing is Single Sign On, not WebAuthn/FIDO. Every site that I've used that has WebAuthn self-hosts it (GitHub, Twitter, Google, Microsoft, etc).
Nothing unless they're on only ones to provide it, or their implementations are the only "trusted" or accepted versions third parties allow you to use.
None, it's just misinformation.
I don't think it's misinformation. You may decide, on your own website, for your own users, to accept passkeys from everybody but others won't.
Sadly enough it's a near guarantee that the less secure implementations of passkeys (the software ones, allowing cloning and backups in the cloud) are likely to be the most accepted.
While actually secure implementation with the secret hidden deep down behind an HSM and never leaving it, made by smaller companies who do care about security, are likely to be rejected on the ground that it's too much of an "obscure" vendor.
I already posted about it today but if you think about it it's literally insane that cloning was meant to be detectable (and detection was enforced and upon detecting a cloned key, one of the two keys would stop working) and that this feature has now been removed with the sole justification being: "Because software backups to the cloud".
It is not good.
Sadly enough it's a near guarantee that the less secure implementations of passkeys (the software ones, allowing cloning and backups in the cloud) are likely to be the most accepted.
While actually secure implementation with the secret hidden deep down behind an HSM and never leaving it, made by smaller companies who do care about security, are likely to be rejected on the ground that it's too much of an "obscure" vendor.
I already posted about it today but if you think about it it's literally insane that cloning was meant to be detectable (and detection was enforced and upon detecting a cloned key, one of the two keys would stop working) and that this feature has now been removed with the sole justification being: "Because software backups to the cloud".
It is not good.
I don't understand how what you say relates to what was said. You don't need to trust Google/Microsoft for your Passkeys, you can use a Yubikey, or whatever else you want.
If Google wants to only accepts its own Passkeys to log in to your Google account, that's as much its choice as any other site has for its authentication.
If Google wants to only accepts its own Passkeys to log in to your Google account, that's as much its choice as any other site has for its authentication.
> that's as much its choice as any other site has for its authentication.
A site having the technical ability to determine not just its authentication mechanism but how that authentication mechanism is stored is not its choice and should not be its choice and is not its business.
And its a clear degradation in user freedom over passwords, a system where it's impossible for Google to dictate that you use only a specific password manager to store and sync that password. It shouldn't be possible for Google to know how I'm storing a passkey.
It's not their right to decide anything about that. They've never had that right. We're not taking a freedom away from Google, we're saying that Google should not have the ability to take away a freedom that we've always had, because they're our devices and it's our login information; it doesn't belong to Google.
A site having the technical ability to determine not just its authentication mechanism but how that authentication mechanism is stored is not its choice and should not be its choice and is not its business.
And its a clear degradation in user freedom over passwords, a system where it's impossible for Google to dictate that you use only a specific password manager to store and sync that password. It shouldn't be possible for Google to know how I'm storing a passkey.
It's not their right to decide anything about that. They've never had that right. We're not taking a freedom away from Google, we're saying that Google should not have the ability to take away a freedom that we've always had, because they're our devices and it's our login information; it doesn't belong to Google.
I suppose the answer is to use Apple, then? It sounds like you have something against attestation, which is a reasonable point, and Apple doesn't support attestation in their implementation of passkeys. Given the size of their customer base, that pretty much guarantees that nobody is going to be denying passkeys based on lack of attestation.
Yeah, I wrote this comment before I knew that Apple was dropping attestation. Them dropping attestation kind of renders the entire conversation moot, practically no one is going to require it if it means cutting off the entire Apple userbase. It's good news.
It's honestly kind of the best possible situation short of attestation being outright removed from the spec. My bank doesn't understand "I should be able to use real 2FA instead of a text message", but they will understand "I should be able to log in from a Mac."
It's honestly kind of the best possible situation short of attestation being outright removed from the spec. My bank doesn't understand "I should be able to use real 2FA instead of a text message", but they will understand "I should be able to log in from a Mac."
What would happen if Apple just started using attestation at a later date? It is still in the spec after all. I could see some services being willing to drop Apple for competitive reasons. ChatGPT only works on Edge browser at the moment IIRC.
:shrug: that would be a very bad problem if it happened.
Removing it from the spec would be better for precisely this reason, but making it harder to use is the next best answer. Bing AI's browser restrictions for example are a pretty big restriction on the service -- that comes with penalties that will discourage many sites from going down that route.
If Google also drops attestation for synced keys then it would become even harder to use attestation, and harder for Apple to go back on its decision. But yes, you're right, it would be better to have stronger guarantees about the future.
Removing it from the spec would be better for precisely this reason, but making it harder to use is the next best answer. Bing AI's browser restrictions for example are a pretty big restriction on the service -- that comes with penalties that will discourage many sites from going down that route.
If Google also drops attestation for synced keys then it would become even harder to use attestation, and harder for Apple to go back on its decision. But yes, you're right, it would be better to have stronger guarantees about the future.
> A site having the technical ability to determine not just its authentication mechanism but how that authentication mechanism is stored is not its choice and should not be its choice and is not its business.
If that site is legally held liable for fraud happening due to credential compromise, as (hopefully!) would be the case for e.g. consumer bank accounts, I'd say there is at least some legitimate interest.
If that site is legally held liable for fraud happening due to credential compromise, as (hopefully!) would be the case for e.g. consumer bank accounts, I'd say there is at least some legitimate interest.
> If that site is legally held liable for fraud happening due to credential compromise, as (hopefully!) would be the case for e.g. consumer bank accounts, I'd say there is at least some legitimate interest.
I kind of disagree honestly. I think consumer bank accounts are some of the least secure accounts I have online. My consumer bank account has removed 2FA options over time. They've literally gone backwards on security.
I don't think there's much evidence that holding banks liable for fraud means that they're going to responsibly make their services more secure. Consumer banks in the US at least are wildly behind the times on account security, and I really don't trust them to make choices about what device I use.
What I do think banks do is invest a lot of effort into looking secure, and I think that stuff like attestation would (if supported) provide an easy mechanism for them to look secure at the same time that they allowed anyone to get into my account with just a social security number and my mother's maiden name. So I feel like, don't even give them the option. There's so much they can do to improve security before we ever start talking about requiring users to use specific hardware devices. Let's have them catch up on basic industry practices before we have that conversation.
I kind of disagree honestly. I think consumer bank accounts are some of the least secure accounts I have online. My consumer bank account has removed 2FA options over time. They've literally gone backwards on security.
I don't think there's much evidence that holding banks liable for fraud means that they're going to responsibly make their services more secure. Consumer banks in the US at least are wildly behind the times on account security, and I really don't trust them to make choices about what device I use.
What I do think banks do is invest a lot of effort into looking secure, and I think that stuff like attestation would (if supported) provide an easy mechanism for them to look secure at the same time that they allowed anyone to get into my account with just a social security number and my mother's maiden name. So I feel like, don't even give them the option. There's so much they can do to improve security before we ever start talking about requiring users to use specific hardware devices. Let's have them catch up on basic industry practices before we have that conversation.
This is certainly true in the US in my experience, but not everywhere globally.
EU regulations require 2FA both for logins on unknown devices and for every transaction initiation (whether on a known/trusted or new session), for example. Often, this happens in the form of dedicated "authenticator apps" that currently take quite frustrating/ineffective security measures like trying to detect whether the device is rooted.
Attestation could at the same time make this actually secure and give users more freedom to e.g. use whatever OS/mod they want to (since the actual root of trust would be an external authenticator or potentially their phone's TEE/Secure Element, not the OS).
EU regulations require 2FA both for logins on unknown devices and for every transaction initiation (whether on a known/trusted or new session), for example. Often, this happens in the form of dedicated "authenticator apps" that currently take quite frustrating/ineffective security measures like trying to detect whether the device is rooted.
Attestation could at the same time make this actually secure and give users more freedom to e.g. use whatever OS/mod they want to (since the actual root of trust would be an external authenticator or potentially their phone's TEE/Secure Element, not the OS).
I guess if this was regulated to be optional or regulated in such a way that it could only be used for keeping keys on-device and couldn't be used for locking out other devices from making accounts, then I'd be OK with it.
But we don't have those regulations in the US, and banks here shouldn't have access to this. We are so behind on security, it just doesn't make sense to give them yet another tool to lock down devices while they're ignoring everything else they could be doing. I would at least advocate for some kind of pact from FIDO Alliance members that attestation will only be implemented for devices sold in countries that have that kind of regulation.
Or, maybe there's a way to do attestation where it's entirely user opt-in and isn't something that the service provider can dictate? Or maybe there's a way to do it where it can't be used to verify the OS/manufacturer during signup, and can only be used to verify that it's the same device where the credentials were created? I think I'd be OK with that existing.
But we don't have those regulations in the US, and banks here shouldn't have access to this. We are so behind on security, it just doesn't make sense to give them yet another tool to lock down devices while they're ignoring everything else they could be doing. I would at least advocate for some kind of pact from FIDO Alliance members that attestation will only be implemented for devices sold in countries that have that kind of regulation.
Or, maybe there's a way to do attestation where it's entirely user opt-in and isn't something that the service provider can dictate? Or maybe there's a way to do it where it can't be used to verify the OS/manufacturer during signup, and can only be used to verify that it's the same device where the credentials were created? I think I'd be OK with that existing.
Are passkeys somehow signed by Google/Apple? I thought passkeys are like ssh keys.
They are, except they have a vendor ID that allows you to tell which vendor made the device you're talking to. You can get Passkeys by any number of vendors, but any authenticating website can decide to only allow a few vendors to log in with it.
Synchronized passkeys by both Apple and Google don't use that mechanism (attestation).
There's also the AAGUID, but without attestation, every implementation is free to provide Apple's or Google's, should websites ever start requiring that.
There's also the AAGUID, but without attestation, every implementation is free to provide Apple's or Google's, should websites ever start requiring that.
> any authenticating website can decide to only allow a few vendors to log in with it.
That's an excellent way of telling your customers you want them to go somewhere else. What's the upside?
That's an excellent way of telling your customers you want them to go somewhere else. What's the upside?
I'm not sure, it sounds silly to me. I guess you can mandate "secure" brands?
"It's just misinformation" is just fancy-speak for "it's bullshit". The former sounds pretentious and (wanna-be) authoritative. I personally prefer the latter form.
With the sad state of PGP on Android, I hope someone picks up development on a viable alternative or ressurrects OpenKeychain. Currently, I cannot use my PGP keys because they're too new on Android.
I think OpenKeyChain is pretty great, I still use it. Unfortunately the authors went commercial (heylogin) and this is why they abandoned it. Their new products are very corporate and not interesting to me as an end user. But OKC is really necessary for my entire flow. I use it with password store, with termux (through OKCAgent) and some other things.
I hope someone else picks it up too, but as long as they incorporate security fixes it's fine. I use yubikeys for the actual encryption anyway so the only risk is in the symmetric part.
But what's the problem with your keys being too new?
I hope someone else picks it up too, but as long as they incorporate security fixes it's fine. I use yubikeys for the actual encryption anyway so the only risk is in the symmetric part.
But what's the problem with your keys being too new?
My ed25519 keys can't decrypt my secrets due to a parsing error somewhere. I can still use okc-ssh-agent to SSH into places, but I cannot decrypt my passwords, which is kind of a big deal. It's because of this I'll probably migrate to a self-hosted bitwarden and use FIDO auth with my yubikey. I'll still use the GPG key for SSH authentication, but boy is this a mess I don't have any time for.
And when I say I don't have the time for, I tried to get OpenKeychain to use a newer version of BouncyCastle, which should support my encrypted files just fine, but boy do I not have the knowledge to deal with changes in a project's gradle structure. I think the root of the issue is that newer versions of GPG have changed the format of the ciphertext in a way that the bouncy castle version OpenKeychain is using doesn't parse. Anyway, I do not feel confident in mucking about in crypto code. Maybe there's hope in just porting a front-end of pass that uses a plain ported GPG implementation instead.
And when I say I don't have the time for, I tried to get OpenKeychain to use a newer version of BouncyCastle, which should support my encrypted files just fine, but boy do I not have the knowledge to deal with changes in a project's gradle structure. I think the root of the issue is that newer versions of GPG have changed the format of the ciphertext in a way that the bouncy castle version OpenKeychain is using doesn't parse. Anyway, I do not feel confident in mucking about in crypto code. Maybe there's hope in just porting a front-end of pass that uses a plain ported GPG implementation instead.
> I think the root of the issue is that newer versions of GPG have changed the format of the ciphertext in a way that the bouncy castle version OpenKeychain is using doesn't parse.
It might be worth your effort to test your hypothesis with an older version of GPG. The LTS version would be especially easy to investigate.
It might be worth your effort to test your hypothesis with an older version of GPG. The LTS version would be especially easy to investigate.
check out psono too for self hosting (https://psono.com/) It's on my todo to do this myself but I haven't had time yet. It looks a lot more interesting to me than self hosted bitwarden/vaultwarden though, especially if you have needs to fill like encrypted file storage that are slightly above and beyond bitwarden's design.
Attestation certificates include detailed information about the device that signed them. Nothing is stopping services from limiting accepted devices to only those approved by the passkey gang (MSFT,AAPL,GOOGL).
Suddenly things that many so readily dismiss as being FUD such as retail Pixel devices' bootloader requiring an internet connection to unlock[1] become much more more relevant.
[1]: https://news.ycombinator.com/item?id=35852192
Suddenly things that many so readily dismiss as being FUD such as retail Pixel devices' bootloader requiring an internet connection to unlock[1] become much more more relevant.
[1]: https://news.ycombinator.com/item?id=35852192
Luckily apple is of the opinion that attestation is a bad idea for adoption and they canned it
> FUD such as retail Pixel devices'
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.
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.
To clarify I'm not against passkeys and WebAuthn, only leery of the gang and their games.
With that out of the way: I'm alright with you, that hypothetical mother of 3, Average Joe, and anyone else accepting the situation as is no matter the reason. Myself, though, however pointless it may be, I haven't given up the fight and I'm likely worse off for it. I suppose that makes me a masochist.
Everything you say is true, and yet none of it relevant for the sceptical and cynical thoughts that I sometimes share here. I don't post those for people who don't care, I post them for my fellow masochists so they don't miss out on whatever new thing I found that we can all get more angry about :)
With that out of the way: I'm alright with you, that hypothetical mother of 3, Average Joe, and anyone else accepting the situation as is no matter the reason. Myself, though, however pointless it may be, I haven't given up the fight and I'm likely worse off for it. I suppose that makes me a masochist.
Everything you say is true, and yet none of it relevant for the sceptical and cynical thoughts that I sometimes share here. I don't post those for people who don't care, I post them for my fellow masochists so they don't miss out on whatever new thing I found that we can all get more angry about :)
To be honest, I was once like you but eventually it is painful to have tons of harddisks and maintain things. Also when I once visited a FSF event and saw many of those so called advocates (telling amazing things in blogs about Libre) were personally using iPhone and NetFlix or every other proprietary service or M1 Apple. Sure, everyone's choice. Then I learned that we all have cognitive dissonance.
> fellow masochists so they don't miss out on whatever new thing I found that we can all get more angry about :)
Ha ha ha!
> fellow masochists so they don't miss out on whatever new thing I found that we can all get more angry about :)
Ha ha ha!
I hear that the big tech vendors (Apple at least) aren't going to do attestable keys.
Must have missed that, thanks. I'm not entirely up to date on this initiative.
Just to be clear I'm not opposed to WebAuthn, I've just gotten very weary of these big corporations - especially when they are banding together and are all super excited about the same thing as we're seeing here :)
Just to be clear I'm not opposed to WebAuthn, I've just gotten very weary of these big corporations - especially when they are banding together and are all super excited about the same thing as we're seeing here :)
> They aren't tied to a device that can be lost, stolen or broken, or requiring you to have multiple devices just in case; and not tied to biometrics.
They optionally can be all of the above, using AAGUIDs and direct attestation.
They optionally can be all of the above, using AAGUIDs and direct attestation.
If even one of the big three refuse to support attestation, then it's dead. And trying to retroactively force attestation at a later date will an even bigger headache than it would be right now.
It's not really a feature for normal passkey users as much as it is for enterprises / government who need to use vetted hardware (e.g. you can only allow AAGUIDs from FIPS YubiKeys).
This doesn't solve anything, sadly.
You are entirely at the behest of Bigco as to whether they will require keys signed by any particular device's certificates, and they have no incentive to allow interoperability here.
You are entirely at the behest of Bigco as to whether they will require keys signed by any particular device's certificates, and they have no incentive to allow interoperability here.
KeePassXC is one of those old style applications that are fast, small, does not change UI every quarter and does well what it was built for. It does not offer "cloud integration", does not send email asking you if you are happy with it and if you want to upgrade to Pro Plan that let you share your passwords with your grandma. Or mine cryptocurrency, ok, this crypto is passe now, nowadays, it would be integration with ChatGPT that would invent better passwords for you...
You put the file on Google Drive, Drop Box, etc. and now you have simple, "distributed" password manager that works on every reasonable platform.
You put the file on Google Drive, Drop Box, etc. and now you have simple, "distributed" password manager that works on every reasonable platform.
Google drive file conflicts fail silently. Putting your key pass file in drive is setting yourself up to lose credentials if you devices sync up at a bad time.
A cloud solution that syncs on a per password basis with end to end encryption offers a more reliable experience.
A cloud solution that syncs on a per password basis with end to end encryption offers a more reliable experience.
That depends on whether you're using synced folders or if you're mounting the Drive as a drive.
Even when mounted (FileStream) uploads are asynchronous and there is no locking
We all know this is mostly meaningless.
The real 'feature' of webAuth is 3rd party attestation.
Your bank and soon every other service will see how 'cheap' it is to fight spam and abuse simply by restricting accounts attested by [apple,google,microsoft] and nobody else, specially 'None' like this one.
When you talk about webAuthn that is what you are talking about in the end. 3rd party attestation. Which in the end will be the end all "privacy respecting" (/s) advertisement profiling tech in the years to come.
The real 'feature' of webAuth is 3rd party attestation.
Your bank and soon every other service will see how 'cheap' it is to fight spam and abuse simply by restricting accounts attested by [apple,google,microsoft] and nobody else, specially 'None' like this one.
When you talk about webAuthn that is what you are talking about in the end. 3rd party attestation. Which in the end will be the end all "privacy respecting" (/s) advertisement profiling tech in the years to come.
> Your bank and soon every other service will see how 'cheap' it is to fight spam and abuse simply by restricting accounts attested by [apple,google,microsoft] and nobody else, specially 'None' like this one.
If that's what they want, they can have it today via OAuth/OIDC (and many sites do just that). It's not a panacea - Google & Co catch some spam accounts but not all of them and not always before the damage is already done.
Passkeys/WebAuthn improve the situation by giving site operators more choices.
If that's what they want, they can have it today via OAuth/OIDC (and many sites do just that). It's not a panacea - Google & Co catch some spam accounts but not all of them and not always before the damage is already done.
Passkeys/WebAuthn improve the situation by giving site operators more choices.
not even close the same thing.
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)
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)
This doesn't need to happen. Having such a function in KeePassXC is important so that there's a sufficient user base not attested by big groups.
KeePass's userbase is negligible, banking apps didn't care about those that use rooted phones and won't care about KeePass users.
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.
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.
What do rooted phones have to do with anything? I use my credit union's app on my rooted, no google play services phone frequently.
A lot of bank apps refuse to work if they detect your device as rooted/failing safetynet. My bank used to do it but they either stopped caring or more probably magisk now handles it so the apps can't tell.
I hear that the big tech vendors (Apple at least) aren't going to do attestable keys.
What do you mean? Apple already offer it.
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.
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.
this is wrong. you're confusing with app attestation. the other reply to this comment is also wrong.
passkey lack the attestation content because the spec doesn't provide for the case being discussed on another thread... cloud backed up keys.
attestation field, per current spec, must attest the 3rd party own the key and it only lives in a single placed (original intent was harware on client validated by vendor keys there)... now obviously we know apple google backup your keys on their cloud, so they cannot attest anything per current spec.
don't takes that as a instance on privacy. they are rushing changes to the spec.
as soon as they can attest keys that are shared with their clouds they will do.
passkey lack the attestation content because the spec doesn't provide for the case being discussed on another thread... cloud backed up keys.
attestation field, per current spec, must attest the 3rd party own the key and it only lives in a single placed (original intent was harware on client validated by vendor keys there)... now obviously we know apple google backup your keys on their cloud, so they cannot attest anything per current spec.
don't takes that as a instance on privacy. they are rushing changes to the spec.
as soon as they can attest keys that are shared with their clouds they will do.
It’s about attested keys, not attested apps. Apple does not attest their software-backed FIDO keys (they call them passkeys).
Isn’t this similar to the trust issues for the x509 CA model?
Basically you’re implicitly trusting that no other CA among those trusted by common browsers will emit a certificate for your domain.
While this isn’t really nice for website certificates, and while there are some safeguards (although the strong ones got deprecated, like http key pinning) … once you go down to the granularity of a single user… not sure how that pans out.
Basically you’re implicitly trusting that no other CA among those trusted by common browsers will emit a certificate for your domain.
While this isn’t really nice for website certificates, and while there are some safeguards (although the strong ones got deprecated, like http key pinning) … once you go down to the granularity of a single user… not sure how that pans out.
Attestation is more like:
The passkey is from this model of security key/phone.
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.
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.
Can someone explain more?
Basically, for hardware backed devices like phones and physical security keys, there's an attestation certificate that is shared by all devices of that model. This can allow a site that wants higher security for some reason to require this kind of proof that the key is protected from copying in hardware (eg bound to a specific device and can't be stolen via malware, theoretically) due to it being a model known to be secure. I'm not aware of specific sites requiring this though.
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...
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...
That seems like truly terrible advice. The only example given:
> It may still be useful to request and store attestation information for future reference - for example, to warn users if security issues are discovered in their authenticators - but we recommend that you do not require a trusted attestation unless you have specific reason to do so.
If that’s the only application, that communication should happen through alternate channels like your browser/OS vendor itself. Having random websites be responsible for communicating whether a given attestation may indicate compromise is less than helpful and the probability of that actually happening correctly is about 0. Oh and given all the breaches, if there is a compromise, the attacker now has a helpful list of customers using compromised authenticators.
One application seems to be to use this to try to replace captcha but I wonder what kind of impact that will have on 3p authenticators. Without extra details, it may be right to be concerned this is a massive landgrab as to how people access online services.
> It may still be useful to request and store attestation information for future reference - for example, to warn users if security issues are discovered in their authenticators - but we recommend that you do not require a trusted attestation unless you have specific reason to do so.
If that’s the only application, that communication should happen through alternate channels like your browser/OS vendor itself. Having random websites be responsible for communicating whether a given attestation may indicate compromise is less than helpful and the probability of that actually happening correctly is about 0. Oh and given all the breaches, if there is a compromise, the attacker now has a helpful list of customers using compromised authenticators.
One application seems to be to use this to try to replace captcha but I wonder what kind of impact that will have on 3p authenticators. Without extra details, it may be right to be concerned this is a massive landgrab as to how people access online services.
After the success of EME, why would anyone expect any different?
I just switched to KeepassXC because KeeWeb is now unmaintained. I really miss the UI simplicity of KeeWeb. Posting this here in case there are any folks reading who are motivated to maintain a Keepass implementation with a far better UX.
https://keeweb.info/
https://keeweb.info/
(last commit from Dec 11, 2022)
Yeah, this isn't new. I've been advocating for this since 2018[1], and the PR in question was submitted in November 2022.
The PR isn't dead though. There's some additional discussion[2] on its current state in the issue I linked above. Basically, it needs more people to test the implementation against different sites in the wild.
Hopefully the increasing popularity of passkeys will provide the necessary level of motivation and support to get this over the finish line.
[1]: https://github.com/keepassxreboot/keepassxc/issues/1870
[2]: https://github.com/keepassxreboot/keepassxc/issues/1870#issu...
The PR isn't dead though. There's some additional discussion[2] on its current state in the issue I linked above. Basically, it needs more people to test the implementation against different sites in the wild.
Hopefully the increasing popularity of passkeys will provide the necessary level of motivation and support to get this over the finish line.
[1]: https://github.com/keepassxreboot/keepassxc/issues/1870
[2]: https://github.com/keepassxreboot/keepassxc/issues/1870#issu...
Eh no? The repo has been committed to 7 hours ago.
Of course the pull request is pending review but that's not too exceptional.
Of course the pull request is pending review but that's not too exceptional.
The repo was committed to, yes, but not the linked PR. The linked PR hasn't been updated since December of last year.
Yes I'm talking about the PR which sadly didn't really receive any recent review activity
This requires a browser with a passkey-providing plugin right? There is no way to use a passkey without browser support, like there is for password managers (copy/paste, or copy it from your phone screen)?
I'm just guessing, but KPXC could emulate a USB device, or - if such things exist - register itself as a security key provider with the operating system
because using a yubikey instead isn't that much more in terms of key-to-browser pipeline - the browser just requests the key from a providing entity
because using a yubikey instead isn't that much more in terms of key-to-browser pipeline - the browser just requests the key from a providing entity
I use KeePassXC on my linux desktops and macbook, but are there any good mobile apps that support it, that I can import my database into?
I have been enjoying Strongbox for passwords plus Mobius Sync (a Syncthing implementation) to keep the password file synced. I am on iOS.
Mobius Sync can sync a file to iOS’ built in file store, and Strongbox can read that. So they work pretty well as a pair.
Mobius Sync can sync a file to iOS’ built in file store, and Strongbox can read that. So they work pretty well as a pair.
I use KeePassium on iOS, synced with Dropbox. Works perfectly. Other sync methods are available too.
Is there now a straightforward way (on both platforms) to use KeePassXC in the role of login keyring/keychain? Last time I looked, admittedly not recently, the answer was “we think you shouldn't want this”.
I don't know, I do everything manually. I remember most of my passwords, but when I forget one I open KeePassXC and copy-paste the pwd into the login. And once every month or so, I'll manually ssh the databases around in a round-robin manner and merge them on every machine. Mainly b/c my pwd database is one thing I don't really want to trust to the cloud, and the manual effort of not doing that isn't too onerous.
I can also recommend using Syncthing for a cloud-less synchronization between the machines
KeePassDX on Android
KeePass2Android is great (for Android) - been using for 5+ years
Am I mistaken, or has the open source community beaten the commercial password managers to implementing WebAuthn?
I'm not sure about other password managers, but this pull request is still open so it's not ready yet.
Bitwarden supports it (for paid accounts)
https://bitwarden.com/help/setup-two-step-login-fido/
https://bitwarden.com/help/setup-two-step-login-fido/
That's not the same thing. Here, KeePassXC supports being a WebAuthn _device_ for logins, whereas linked is how you can use WebAuthn to log _into_ bitwarden. The former is basically (?) emulating the device, whereas the latter is just supporting it for vault logins
I understand the difference now. Thanks!
1Password already has a beta/demo of this I believe.
I thought passkeys are always stored in secure enclaves and can't be exported?
No, Passkeys are just some random data and cryptography.
However, the most popular implementations (like in iOS/macOS) use TouchID/FaceID/Passcode to protect access to the passkey.
That doesn't preclude other implementations from doing it other ways.
However, the most popular implementations (like in iOS/macOS) use TouchID/FaceID/Passcode to protect access to the passkey.
That doesn't preclude other implementations from doing it other ways.
That is, there is no vendor lock in to multinational corps only interested in their bottom line and selling your data. They aren't tied to a device that can be lost, stolen or broken, or requiring you to have multiple devices just in case; and not tied to biometrics.
Lastly this means there is a proper open source, offline version that is portable across devices, browsers, and ecosystems. Putting the user back in control.