5 ms·

No passkeys are just normal private keys. You can store those private keys in a particular platform's secure key store which on phones can be decrypted/made usa

No passkeys are just normal private keys. You can store those private keys in a particular platform's secure key store which on phones can be decrypted/made usable when you unlock the device. But there is nothing stopping you from transferring these keys to a different device if you wish.

lxgr 3y ago
True, Passkeys are private keys at heart, but relying parties can verify whether they are stored in software or hardware by requesting/requiring authenticator attestation when they are created.
- dcow 3y ago
  And certain hardware from certain platform vendors doesn't allow exfiltration of private key material. Though I don't think this can be specified by the relying party so that's how Apple stores all keys in keychai. I sincerely hope it remains best practice for relying parties to not require/use the platform attestation feature to lock users onto "trusted" platforms.
  - lxgr 3y ago
    Device binding can be required by relying parties! They can just refuse to accept credentials without attestation statements signed by a trusted party. My government e-signature service does that: I can’t even use a Yubikey, ironically, because that’s not "FIDO level 2 certified". I had to buy a more or less completely unknown brand instead (of which a government affiliate is apparently the exclusive reseller in my country…)
    - dcow 3y ago
      That's more like vendor binding. Apple’s credentials aren’t device bound so “pinning” to Apple as a vendor by requiring attestation doesn't ensure a credential is device-bound. Not that you don’t have a point, generally.
michaelt 3y ago
So if I transfer a passkey to my Yubikey, which has a single button and no pin, thus achieving 1-factor authentication - is that undetectable to the website? Because sources like [1] say that "A passkey can replace a password and a second factor in a single step" and "a biometric sensor (such as a fingerprint or facial recognition), PIN, or pattern" - isn't there something in the standard that ensures the second factor is maintained? [1] https://developers.google.com/identity/passkeys https://developers.google.com/identity/passkeys
- Veliladon 3y ago
  You wouldn't transfer a passkey to your YubiKey. You would enroll it as another device that can be used to login. Like right now on my Google account I have an iCloud passkey and a Windows Hello passkey since iCloud can't sync a passkey to Windows (yet).
  - dotancohen 3y ago
    Hypothetical political journalist just lost both his Yubikeys when his office and home were both targeted. He still has an off-site backup of his passkey. How would you envision this working?
    - dwattttt 3y ago
      I'm unfamiliar with the particulars of passkeys, but with hardware tokens I've used before, you'd log in ASAP and unenroll the keys you've lost custody of. edit: spelling
  - cookiengineer 3y ago
    So this is basically the same thing like ssh keys?
    - Veliladon 3y ago
      Exactly. But with some added security.
howinteresting 3y ago
How exactly would you transfer your iOS passkeys to Android? Please provide an enumerated list of steps.
danShumway 3y ago
> But there is nothing stopping you from transferring these keys to a different device if you wish. Importantly, I don't think there's a single implementation of Passkey that actually allows this. In theory you could move your keys but in practice, there is no way to transfer your private keys off of your phone. There's also nothing in the spec that forces any provider to allow transfer, so I don't expect that to change any time soon. And even if you can transfer your keys (which you can't) there's also nothing in the spec other than "please don't do this" language that stops a site from using attestation to restrict sign-in from other devices that you've transferred your keys to. It is very locked down right now.
- dwaite 3y ago
  > Importantly, I don't think there's a single implementation of Passkey that actually allows this. In theory you could move your keys but in practice, there is no way to transfer your private keys off of your phone The google password manager and Apple devices will sync private keys as part of the password manager sync fabric. They are on all devices. In addition, the 'share password' option on Apple devices works with passkeys. To deter social engineering, the person needs to be in your contacts, and in proximity to receive an airdrop. There's nothing (other than say future certification marks) to prevent software exporting via a CSV file, the same way many password managers export/import credentials today.
  - danShumway 3y ago
    > The google password manager and Apple devices will sync private keys as part of the password manager sync fabric. This is really misleading -- you can not move a passkey "vault" from an Apple device to an Android device without doing a per-password operation. There are no Open implementations of a passkey authenticator and there is no standard format defined in the spec for how to do mass movement. There are huge caveats to this that people are just glossing over and saying "yeah, they're portable, don't worry about it." It makes it really hard to trust passkey proponents when they talk about what's going to be supported in the future, because even the present support level is constantly being misrepresented. So how am I supposed to take their claims about what the future will look like if I can't trust them to talk about the present? I mean, you bring up Airdrop. I feel like I need to check, is something changed and that now works on Android devices? I'd love to be wrong about this, but Apple's documentation doesn't mention airdropping a passkey to an Android device: https://support.apple.com/guide/iphone/share-passkeys-passwords-securely-airdrop-iph0dd1796bb/ios https://support.apple.com/guide/iphone/share-passkeys-passwo... That kind of platform lock-in seems like it would be an important caveat to mention when talking about backup. But I never see stuff like this mentioned. I don't see how anyone could genuinely claim that passkey portability is exactly the same as an SSH key or password. That's just not true. Authenticating a second device per-site is not the same thing as a cross-platform backup. > They are on all devices. They're not on a Linux desktop. If you want to use passkey on a Linux desktop, your options are to authenticate through a secondary proprietary device or to use a Yubikey -- for all practical purposes a locked down device which can not be backed up (no, buying a second Yubikey and manually adding it site-by-site is not the same as backup). > There's nothing (other than say future certification marks) to prevent software exporting via a CSV file, the same way many password managers export/import credentials today. And yet, none of them allow it. I keep getting told that nothing is preventing this, but... it's not supported. And again, nothing in the spec requires it. This is asking for vendor lock-in. If it's not a big deal and everyone's going to support syncing across ecosystems, then it shouldn't be a big deal to add a standardized API and sync format to the requirements for being a certified provider.
vinay_ys 3y ago
This is incorrect. Passkeys on iOS and Android are locked to Apple and Google account ecosystem. They cannot leave their ecosystem. Also, only the OS platform can use the BLE transport for CTAP2 protocol on iOS and Android devices. That is, a 3rdparty app (like 1password) cannot implement a FIDO2 BLE or NFC authenticator on iOS and Android – which is a huge handicap.

lxgr 3y ago

True, Passkeys are private keys at heart, but relying parties can verify whether they are stored in software or hardware by requesting/requiring authenticator attestation when they are created.

dcow 3y ago
And certain hardware from certain platform vendors doesn't allow exfiltration of private key material. Though I don't think this can be specified by the relying party so that's how Apple stores all keys in keychai. I sincerely hope it remains best practice for relying parties to not require/use the platform attestation feature to lock users onto "trusted" platforms.
- lxgr 3y ago
  Device binding can be required by relying parties! They can just refuse to accept credentials without attestation statements signed by a trusted party. My government e-signature service does that: I can’t even use a Yubikey, ironically, because that’s not "FIDO level 2 certified". I had to buy a more or less completely unknown brand instead (of which a government affiliate is apparently the exclusive reseller in my country…)
  - dcow 3y ago
    That's more like vendor binding. Apple’s credentials aren’t device bound so “pinning” to Apple as a vendor by requiring attestation doesn't ensure a credential is device-bound. Not that you don’t have a point, generally.

michaelt 3y ago

So if I transfer a passkey to my Yubikey, which has a single button and no pin, thus achieving 1-factor authentication - is that undetectable to the website? Because sources like [1] say that "A passkey can replace a password and a second factor in a single step" and "a biometric sensor (such as a fingerprint or facial recognition), PIN, or pattern" - isn't there something in the standard that ensures the second factor is maintained? [1] https://developers.google.com/identity/passkeys https://developers.google.com/identity/passkeys

Veliladon 3y ago
You wouldn't transfer a passkey to your YubiKey. You would enroll it as another device that can be used to login. Like right now on my Google account I have an iCloud passkey and a Windows Hello passkey since iCloud can't sync a passkey to Windows (yet).
- dotancohen 3y ago
  Hypothetical political journalist just lost both his Yubikeys when his office and home were both targeted. He still has an off-site backup of his passkey. How would you envision this working?
  - dwattttt 3y ago
    I'm unfamiliar with the particulars of passkeys, but with hardware tokens I've used before, you'd log in ASAP and unenroll the keys you've lost custody of. edit: spelling
- cookiengineer 3y ago
  So this is basically the same thing like ssh keys?
  - Veliladon 3y ago
    Exactly. But with some added security.

howinteresting 3y ago

How exactly would you transfer your iOS passkeys to Android? Please provide an enumerated list of steps.

danShumway 3y ago

> But there is nothing stopping you from transferring these keys to a different device if you wish. Importantly, I don't think there's a single implementation of Passkey that actually allows this. In theory you could move your keys but in practice, there is no way to transfer your private keys off of your phone. There's also nothing in the spec that forces any provider to allow transfer, so I don't expect that to change any time soon. And even if you can transfer your keys (which you can't) there's also nothing in the spec other than "please don't do this" language that stops a site from using attestation to restrict sign-in from other devices that you've transferred your keys to. It is very locked down right now.

dwaite 3y ago
> Importantly, I don't think there's a single implementation of Passkey that actually allows this. In theory you could move your keys but in practice, there is no way to transfer your private keys off of your phone The google password manager and Apple devices will sync private keys as part of the password manager sync fabric. They are on all devices. In addition, the 'share password' option on Apple devices works with passkeys. To deter social engineering, the person needs to be in your contacts, and in proximity to receive an airdrop. There's nothing (other than say future certification marks) to prevent software exporting via a CSV file, the same way many password managers export/import credentials today.
- danShumway 3y ago
  > The google password manager and Apple devices will sync private keys as part of the password manager sync fabric. This is really misleading -- you can not move a passkey "vault" from an Apple device to an Android device without doing a per-password operation. There are no Open implementations of a passkey authenticator and there is no standard format defined in the spec for how to do mass movement. There are huge caveats to this that people are just glossing over and saying "yeah, they're portable, don't worry about it." It makes it really hard to trust passkey proponents when they talk about what's going to be supported in the future, because even the present support level is constantly being misrepresented. So how am I supposed to take their claims about what the future will look like if I can't trust them to talk about the present? I mean, you bring up Airdrop. I feel like I need to check, is something changed and that now works on Android devices? I'd love to be wrong about this, but Apple's documentation doesn't mention airdropping a passkey to an Android device: https://support.apple.com/guide/iphone/share-passkeys-passwords-securely-airdrop-iph0dd1796bb/ios https://support.apple.com/guide/iphone/share-passkeys-passwo... That kind of platform lock-in seems like it would be an important caveat to mention when talking about backup. But I never see stuff like this mentioned. I don't see how anyone could genuinely claim that passkey portability is exactly the same as an SSH key or password. That's just not true. Authenticating a second device per-site is not the same thing as a cross-platform backup. > They are on all devices. They're not on a Linux desktop. If you want to use passkey on a Linux desktop, your options are to authenticate through a secondary proprietary device or to use a Yubikey -- for all practical purposes a locked down device which can not be backed up (no, buying a second Yubikey and manually adding it site-by-site is not the same as backup). > There's nothing (other than say future certification marks) to prevent software exporting via a CSV file, the same way many password managers export/import credentials today. And yet, none of them allow it. I keep getting told that nothing is preventing this, but... it's not supported. And again, nothing in the spec requires it. This is asking for vendor lock-in. If it's not a big deal and everyone's going to support syncing across ecosystems, then it shouldn't be a big deal to add a standardized API and sync format to the requirements for being a certified provider.

vinay_ys 3y ago

This is incorrect. Passkeys on iOS and Android are locked to Apple and Google account ecosystem. They cannot leave their ecosystem. Also, only the OS platform can use the BLE transport for CTAP2 protocol on iOS and Android devices. That is, a 3rdparty app (like 1password) cannot implement a FIDO2 BLE or NFC authenticator on iOS and Android – which is a huge handicap.