3 ms·

Passkeys support an attestation anti-feature, enshrined in the spec. This feature can be abused (and will be IMO, why put it in the spec otherwise?) to limit wh

Passkeys support an attestation anti-feature, enshrined in the spec. This feature can be abused (and will be IMO, why put it in the spec otherwise?) to limit which providers can access a service. Lock-in is built into the design. One of the developers already threatened to use it against keepass when they built an export feature he didn't agree with.

parliament32 1y ago
Attestation is probably the best feature of passkeys. From a corporate compliance perspective, I need to ensure that employee keys are stored in a FIPS-compliant TPM and unexportable. Key loss is not an issue because we have, ya know, an IT department. The only way I can ensure this happens is by whitelisting AAGUIDs and enforcing attestation. With these factors I can also get out of the MFA hellhole (because I can prove that whitelisted vendor X already performs MFA on-device without me having to manage it: for example, WHFB requires something you have (keys in your TPM) and either something you are (face scan / fingerprint) or something you know (PIN), without me having to store/verify any of those factors or otherwise manage them). Same goes for passkeys stored in MS Authenticator on iOS/Android.
- yladiz 1y ago
  But most passkey providers don’t return attestation data. How do you get the data?
  - parliament32 1y ago
    Attestation is not provided by the passkey provider itself, but the OS. For example, iOS uses the App Attest service (https://developer.apple.com/documentation/devicecheck/preparing-to-use-the-app-attest-service https://developer.apple.com/documentation/devicecheck/prepar...). On Android, you get it from Google Play Services (https://developer.android.com/google/play/integrity/overview https://developer.android.com/google/play/integrity/overview) then the built in key attest service (https://developer.android.com/privacy-and-security/security-key-attestation https://developer.android.com/privacy-and-security/security-...). MS Authenticator does all the legwork and returns the results to you at sign-in time. On Windows, WHFB has this built in (obviously). On macOS, this comes from Platform SSO (https://support.apple.com/en-ca/guide/deployment/dep7bbb05313/web https://support.apple.com/en-ca/guide/deployment/dep7bbb0531...).
- coldpie 1y ago
  This is fine for corporate settings, where the data is not owned by the user but by the company. But it's completely unacceptable for managing one's own personal account. What do I do if I do not trust proprietary software to manage my ability to log in to online services? How can this be compatible with open source passkey providers? The spec failing to distinguish between these two cases is a major flaw and completely kills passkey viability for personal accounts until they resolve it.
  - deleted 1y ago
    [deleted]
  - WorldMaker 1y ago
    Apple has stated very publicly and in multiple places/ways that Consumer Passkeys will never include attestation data on Apple hardware. That's not "the spec", but it is still currently a big enough moat to protect Consumer usage of passkeys away from Corporate needs, given most Consumer apps/websites probably want iOS/iPadOS/macOS (in decreasing interest) users today.
    - coldpie 1y ago
      > Apple has stated very publicly and in multiple places/ways that Consumer Passkeys will never include attestation data on Apple hardware. I'm interested in reading more about this. Do you have some links? I did some quick searching of the terms you mentioned and nothing obvious came up.
      - WorldMaker 1y ago
        Yeah, it's unfortunate we live in an age where searching for things is harder and less likely to turn up the results from even a couple months ago. Some quick bits and pieces from my own searching just now: Apple's documentation on Passkey attestation is entirely under "declarative configuration", their terminology for mobile device management (MDM) corporate tools: https://support.apple.com/guide/deployment/passkey-attestation-declarative-configuration-depd218e61b5/web https://support.apple.com/guide/deployment/passkey-attestati... It is noticeably absent from, for instance, AuthenticationServices documentation: https://developer.apple.com/documentation/authenticationservices/supporting-passkeys https://developer.apple.com/documentation/authenticationserv... On non-attestation Passkey responses intentionally send an empty AAGUID for privacy/Apple's belief in the spec's suggestion to send an empty AAGUID: > iCloud Keychain is one of the few (maybe the only?) passkey authenticator that currently follows the spec and will use an all-zero AAGUID. From: https://developer.apple.com/forums/thread/739004 https://developer.apple.com/forums/thread/739004 On the technical side of limitations of attestation for consumer Passkeys (due to iCloud Keychain sync): > Passkeys do not provide an attestation statement, as the attestation model currently defined in WebAuthn wasn't designed with syncing credentials in mind. > Attestation was designed to attest to a specific device, exclusively at the point of creation, with a specific set of security properties. It doesn't make sense for synced credentials for a number of reasons, including syncing to devices with different security properties, changes in security properties that happen after key creation, security properties of the sync fabric, sharing the passkey, or exporting to other passkey providers. We're working hard with W3C and FIDO to solve these problems. From: https://developer.apple.com/forums/thread/708982 https://developer.apple.com/forums/thread/708982 (I believe some of the problems being solved in that one in 2022 is referring to how we got the "uvi" and "uvm" extensions to Passkeys, neither of which is in attestation data nor attested in any way, and both designed for a general semblance of user privacy: https://www.w3.org/TR/webauthn-1/#sctn-uvi-extension https://www.w3.org/TR/webauthn-1/#sctn-uvi-extension) I believe the juiciest quotes I'm looking for are buried in WWDC videos and I can't find a transcript search tool just yet.
- immibis 1y ago
  Attestation is probably the worst feature of passkeys. From a freedom perspective, I need to ensure that Google has no idea whether my device is an Android phone bought from an officially licensed manufacturer, or Waydroid or android-x86. Compliance is not an issue because I am, ya know, some random guy. The only way I can ensure this happens is by ensuring attestation is not possible.
cyberax 1y ago
> Passkeys support an attestation anti-feature, enshrined in the spec. This feature can be abused (and will be IMO, why put it in the spec otherwise?) to limit which providers can access a service. The problem is that Passkeys really conflate two separate feature sets: 1. Synchronized password replacements. They _have_ to be represented as accessible clear-text to be synced between devices, at least during transit. So they can be stolen, for example, by malware that scans RAM for keys. 2. Keys that never leave a hardened hardware devices. Since they never leave the device, they can't be synced. But they're completely secure.
- lxgr 1y ago
  This is largely a problem because the specification does not cleanly call these out as two completely different feature sets, e.g. via "profiles" or a similar mechanism. Effectively implementations already do that, and the spec could clear things up a lot by clearly defining one profile for synchronizing, non-attestation-capable, discoverable credentials called "passkeys", and another for hardware-backed, non-exportable, attestation-supporting ones called something else.
  - cyberax 1y ago
    Yes, clearly separating these two use-cases would have helped immensely. This technically is true because Passkeys are just a subset of WebAuth.
lxgr 1y ago
None of the common passkey implementations support attestation. Apple doesn't support it at all anymore; Google only supports it for non-synchronized credentials (which are arguably not passkeys). Bitwarden obviously doesn't either (it can't, as a pure software implementation). > One of the developers already threatened to use it against keepass when they built an export feature he didn't agree with. Developer of what? There's no competing software solution that supports attestation, and hardware authenticators complement software ones, rather than compete with them.
- proactivesvcs 1y ago
  https://github.com/timcappalli https://github.com/timcappalli, "passkeys, FIDO2/WebAuthn, and digital credentials @ okta" Not directly threatening but within that frame of mind: https://github.com/keepassxreboot/keepassxc/issues/10407#issuecomment-1994673954 https://github.com/keepassxreboot/keepassxc/issues/10407#iss... https://github.com/keepassxreboot/keepassxc/issues/10407#issuecomment-1994182200 https://github.com/keepassxreboot/keepassxc/issues/10407#iss...

parliament32 1y ago

Attestation is probably the best feature of passkeys. From a corporate compliance perspective, I need to ensure that employee keys are stored in a FIPS-compliant TPM and unexportable. Key loss is not an issue because we have, ya know, an IT department. The only way I can ensure this happens is by whitelisting AAGUIDs and enforcing attestation. With these factors I can also get out of the MFA hellhole (because I can prove that whitelisted vendor X already performs MFA on-device without me having to manage it: for example, WHFB requires something you have (keys in your TPM) and either something you are (face scan / fingerprint) or something you know (PIN), without me having to store/verify any of those factors or otherwise manage them). Same goes for passkeys stored in MS Authenticator on iOS/Android.

yladiz 1y ago
But most passkey providers don’t return attestation data. How do you get the data?
- parliament32 1y ago
  Attestation is not provided by the passkey provider itself, but the OS. For example, iOS uses the App Attest service (https://developer.apple.com/documentation/devicecheck/preparing-to-use-the-app-attest-service https://developer.apple.com/documentation/devicecheck/prepar...). On Android, you get it from Google Play Services (https://developer.android.com/google/play/integrity/overview https://developer.android.com/google/play/integrity/overview) then the built in key attest service (https://developer.android.com/privacy-and-security/security-key-attestation https://developer.android.com/privacy-and-security/security-...). MS Authenticator does all the legwork and returns the results to you at sign-in time. On Windows, WHFB has this built in (obviously). On macOS, this comes from Platform SSO (https://support.apple.com/en-ca/guide/deployment/dep7bbb05313/web https://support.apple.com/en-ca/guide/deployment/dep7bbb0531...).
coldpie 1y ago
This is fine for corporate settings, where the data is not owned by the user but by the company. But it's completely unacceptable for managing one's own personal account. What do I do if I do not trust proprietary software to manage my ability to log in to online services? How can this be compatible with open source passkey providers? The spec failing to distinguish between these two cases is a major flaw and completely kills passkey viability for personal accounts until they resolve it.
- deleted 1y ago
  [deleted]
- WorldMaker 1y ago
  Apple has stated very publicly and in multiple places/ways that Consumer Passkeys will never include attestation data on Apple hardware. That's not "the spec", but it is still currently a big enough moat to protect Consumer usage of passkeys away from Corporate needs, given most Consumer apps/websites probably want iOS/iPadOS/macOS (in decreasing interest) users today.
  - coldpie 1y ago
    > Apple has stated very publicly and in multiple places/ways that Consumer Passkeys will never include attestation data on Apple hardware. I'm interested in reading more about this. Do you have some links? I did some quick searching of the terms you mentioned and nothing obvious came up.
    - WorldMaker 1y ago
      Yeah, it's unfortunate we live in an age where searching for things is harder and less likely to turn up the results from even a couple months ago. Some quick bits and pieces from my own searching just now: Apple's documentation on Passkey attestation is entirely under "declarative configuration", their terminology for mobile device management (MDM) corporate tools: https://support.apple.com/guide/deployment/passkey-attestation-declarative-configuration-depd218e61b5/web https://support.apple.com/guide/deployment/passkey-attestati... It is noticeably absent from, for instance, AuthenticationServices documentation: https://developer.apple.com/documentation/authenticationservices/supporting-passkeys https://developer.apple.com/documentation/authenticationserv... On non-attestation Passkey responses intentionally send an empty AAGUID for privacy/Apple's belief in the spec's suggestion to send an empty AAGUID: > iCloud Keychain is one of the few (maybe the only?) passkey authenticator that currently follows the spec and will use an all-zero AAGUID. From: https://developer.apple.com/forums/thread/739004 https://developer.apple.com/forums/thread/739004 On the technical side of limitations of attestation for consumer Passkeys (due to iCloud Keychain sync): > Passkeys do not provide an attestation statement, as the attestation model currently defined in WebAuthn wasn't designed with syncing credentials in mind. > Attestation was designed to attest to a specific device, exclusively at the point of creation, with a specific set of security properties. It doesn't make sense for synced credentials for a number of reasons, including syncing to devices with different security properties, changes in security properties that happen after key creation, security properties of the sync fabric, sharing the passkey, or exporting to other passkey providers. We're working hard with W3C and FIDO to solve these problems. From: https://developer.apple.com/forums/thread/708982 https://developer.apple.com/forums/thread/708982 (I believe some of the problems being solved in that one in 2022 is referring to how we got the "uvi" and "uvm" extensions to Passkeys, neither of which is in attestation data nor attested in any way, and both designed for a general semblance of user privacy: https://www.w3.org/TR/webauthn-1/#sctn-uvi-extension https://www.w3.org/TR/webauthn-1/#sctn-uvi-extension) I believe the juiciest quotes I'm looking for are buried in WWDC videos and I can't find a transcript search tool just yet.
immibis 1y ago
Attestation is probably the worst feature of passkeys. From a freedom perspective, I need to ensure that Google has no idea whether my device is an Android phone bought from an officially licensed manufacturer, or Waydroid or android-x86. Compliance is not an issue because I am, ya know, some random guy. The only way I can ensure this happens is by ensuring attestation is not possible.

cyberax 1y ago

> Passkeys support an attestation anti-feature, enshrined in the spec. This feature can be abused (and will be IMO, why put it in the spec otherwise?) to limit which providers can access a service. The problem is that Passkeys really conflate two separate feature sets: 1. Synchronized password replacements. They _have_ to be represented as accessible clear-text to be synced between devices, at least during transit. So they can be stolen, for example, by malware that scans RAM for keys. 2. Keys that never leave a hardened hardware devices. Since they never leave the device, they can't be synced. But they're completely secure.

lxgr 1y ago
This is largely a problem because the specification does not cleanly call these out as two completely different feature sets, e.g. via "profiles" or a similar mechanism. Effectively implementations already do that, and the spec could clear things up a lot by clearly defining one profile for synchronizing, non-attestation-capable, discoverable credentials called "passkeys", and another for hardware-backed, non-exportable, attestation-supporting ones called something else.
- cyberax 1y ago
  Yes, clearly separating these two use-cases would have helped immensely. This technically is true because Passkeys are just a subset of WebAuth.

lxgr 1y ago

None of the common passkey implementations support attestation. Apple doesn't support it at all anymore; Google only supports it for non-synchronized credentials (which are arguably not passkeys). Bitwarden obviously doesn't either (it can't, as a pure software implementation). > One of the developers already threatened to use it against keepass when they built an export feature he didn't agree with. Developer of what? There's no competing software solution that supports attestation, and hardware authenticators complement software ones, rather than compete with them.

proactivesvcs 1y ago
https://github.com/timcappalli https://github.com/timcappalli, "passkeys, FIDO2/WebAuthn, and digital credentials @ okta" Not directly threatening but within that frame of mind: https://github.com/keepassxreboot/keepassxc/issues/10407#issuecomment-1994673954 https://github.com/keepassxreboot/keepassxc/issues/10407#iss... https://github.com/keepassxreboot/keepassxc/issues/10407#issuecomment-1994182200 https://github.com/keepassxreboot/keepassxc/issues/10407#iss...