5 ms·

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 authentica

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).

lxgr 3y ago
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).
- danShumway 3y ago
  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-attestation-dep28afbde6a/web 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.
  - lxgr 3y ago
    https://www.slashid.dev/blog/passkeys-deepdive/ 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.
    - danShumway 3y ago
      Well heck, I'm very happy you chimed in on this, thanks. Very happy surprise.
      - lxgr 3y ago
        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.
brookst 3y ago
> 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).
- danShumway 3y ago
  > 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.
sebk 3y ago
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.
- danShumway 3y ago
  > 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.

lxgr 3y ago

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).

danShumway 3y ago
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-attestation-dep28afbde6a/web 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.
- lxgr 3y ago
  https://www.slashid.dev/blog/passkeys-deepdive/ 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.
  - danShumway 3y ago
    Well heck, I'm very happy you chimed in on this, thanks. Very happy surprise.
    - lxgr 3y ago
      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.

brookst 3y ago

> 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).

danShumway 3y ago
> 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.

sebk 3y ago

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.

danShumway 3y ago
> 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.