11 ms·

This is based on the open standards WebAuthn and FIDO2, where the credentials (“passkeys”) are synced via iCloud Keychain. Currently you need remember to regist

by zxcvgm 4y ago

This is based on the open standards WebAuthn and FIDO2, where the credentials (“passkeys”) are synced via iCloud Keychain. Currently you need remember to register at least 2 security keys, in case one is lost/misplaced. The syncing of passkeys in iCloud solves this backup problem. https://fidoalliance.org/apple-google-and-microsoft-commit-to-expanded-support-for-fido-standard-to-accelerate-availability-of-passwordless-sign-ins/ https://fidoalliance.org/apple-google-and-microsoft-commit-t...

gsibble 4y ago
How will this work on Linux?
- psanford 4y ago
  FIDO usb devices just use the HID protocol so they work fine on linux. Chrome and Firefox both support them. I wrote a FIDO implementation that protects the signing key using the system's TPM specifically for linux: https://github.com/psanford/tpm-fido https://github.com/psanford/tpm-fido There is no reason why you couldn't implement a similar syncing strategy in a tool like this if you wanted to.
  - balena 4y ago
    Isn't this approach significantly less secure than Apple's though? As far as I understand the secure enclave coprocessor in Apple devices stores key material and implements user verification (TouchID etc.), right? Instead software like tpm-fido bridges (in software) a user verification mechanism (maybe even a fingerprint reader) and the system's TPM. But such a system can be interposed with mere root access, and the TPM tricked in giving out its secrets, no? Please correct me if I'm getting it wrong, but Apple's approach is instead resistant even to full kernel compromise, precisely because the communication between TouchID/FaceID and the secure enclave cannot be interposed. I'm a tpm-fido user myself by the way, thank you psanford!
    - psanford 4y ago
      Yes, having the verification done by the secure enclave itself is more secure. The TPM spec does allow for direct integration with biometric devices, but I'm not aware of any general purpose computers that ship in this configuration. > TPM tricked in giving out its secrets To be clear, the key can never leave the TPM (with how tpm-fido is implemented). The threat is an attacker can perform an online attack by getting the TPM to sign messages it shouldn't. But you couldn't steal the key from the TPM and use it somewhere else. But it doesn't really matter for the Webauthn threat model. An attacker with root access can steal your browser sessions directly.
      - balena 4y ago
        > To be clear, the key can never leave the TPM (with how tpm-fido is implemented). Yep sorry you're right you wouldn't get the actual keys to use elsewhere, you can just use them as if you had them on the "compromised" device only, my bad. > But it doesn't really matter for the Webauthn threat model. An attacker with root access can steal your browser sessions directly. If you're using WebAuthn to authorize the emission of session tokens you're absolutely right, just get root and steal them from the browser :) but WebAuthn is more versatile than that. You could e.g. require a WebAuthn assertion to authorize a payment. In that case root access still doesn't help you with a secure enclave, but is sufficient to trick your server in believing the user has authorized the operation with tpm-fido, right? Again I absolutely don't mean to detract from tpm-fido, just pointing out that, very sadly, I don't think a TPM+fingerprint reader+software can really replace integrated solutions like Apple's secure enclave, or a yubikey, etc. In general unless I'm mistaken, it's not a tpm-fido shortcoming specifically.
        psanford 4y ago
        I agree that the secure enclave with integrated touch id is more secure. However, if your threat model is an attacker has root on your system, the secure enclave isn't going to protect you from much.
        mwwaters 4y ago
        A compromised main UI device could also show the wrong account recipient, even if hardware key is used. The text could be changed on the screen when the user meant to send a small payment to someone else. Yubikey will be pressed like usual. Apple's standard prompt on the phone may not have the recipient shown.
  - tialaramex 4y ago
    > just use the HID protocol This is literally true, and covers what was important in context, but warrants a little extra explanation. Since these devices are specifically for humans to interface with (they typically have a button or contact sensor, though some have keypads or a fingerprint reader) they are logically Human Interface Device class USB devices, but they do not speak the HID Keyboard or Pointing Device sub-protocols like your mouse or keyboard (or the built-in "take a photo" button on your web cam). Instead they provide a FIDO-specific HID sub-protocol, which is publicly documented, instead of operations like "Caps Lock pressed" it's got stuff like "Begin enrolment" or "PIN xxxx entered by the user" which only makes sense for this specific problem.
    - ptman 4y ago
      some yubikey modes of operation do emulate keyboards and paste a string of characters in text fields or terminals
      - tialaramex 4y ago
        They do, and an earlier version of my post mentioned that but I edited it down. However, FIDO mode does not speak the keyboard sub-protocol. This means on the one hand it's not useable out of the box with some random device that allows USB keyboard input like the custom Yubico OTP mode is, but on the other hand it's able to deliver a good UX while having excellent security properties that would not be practical using keyboard emulation.
    - _ea1k 4y ago
      Oh, thanks for the explanation. I guess this new protocol is why I don't see as many tokens randomly appearing in chat sessions these days.
  - tkanarsky 4y ago
    Oh dang, thanks for writing tpm-fido! It works really well for my use case -- avoiding mandatory and incredibly annoying Duo Mobile 2fa on my school's website -- although I tore the presence verification out of the code for my purposes :) iirc, this relies on the uhid module to mock a physical fido2 key, and I'm not sure if there's a way to present a mock fido2 key OS-wide without relying on a virtual USB device. This was a bit of an issue when I tried setting up a similar fido2 emulator in a container, as the Google container OS doesn't allow loading kernel modules. Do you know if that's still the case, or if there's a way to mock a fido2 key systemwide without uhid?
    - psanford 4y ago
      > there's a way to mock a fido2 key systemwide without uhid? On Linux, Chrome and Firefox interface directly with the USB and Bluetooth interfaces. There is no OS level abstraction for FIDO devices on Linux.
  - raxxorraxor 4y ago
    Is there a software implementation that would work without a TPM module where I can generate the keys myself?
    - psanford 4y ago
      Check out rust-u2f/softu2f[0]. [0]: https://github.com/danstiner/rust-u2f https://github.com/danstiner/rust-u2f
Vladimof 4y ago
> The syncing of passkeys in iCloud solves this backup problem. But then apple has your keys....
- jtokoph 4y ago
  I would assume that they are at least encrypted locally before being uploaded to iCloud. (But yes, Apple could always change things)
  - SamuelAdams 4y ago
    Don’t be so certain - we need more details from Apple on this. Last I checked iMessage was still (!) not encrypted when backed up to iCloud. https://www.howtogeek.com/710509/apples-imessage-is-secure...-unless-you-have-icloud-enabled/ https://www.howtogeek.com/710509/apples-imessage-is-secure.....
    - judge2020 4y ago
      iCloud Keychain is end-to-end encrypted, Messages isn't because Apple took the tradeoff of allowing people to keep their imessage history even upon a support-initiated account reset, which otherwise will wipe your entire iCloud Keychain.
      - reshlo 4y ago
        Messages is end-to-end encrypted. The key is stored in iCloud backups if they’re enabled (and if I recall correctly the messages on your device are backed up as part of an iCloud backup as well), but you can turn those backups off. > [1]For Messages in iCloud, if you have iCloud Backup turned on, your backup includes a copy of the key protecting your messages. This ensures you can recover your messages if you lose access to your Keychain and your trusted devices. When you turn off iCloud Backup, a new key is generated on your device to protect future messages and isn't stored by Apple. > If you forget your password or device passcode, iCloud Data Recovery Service can help you decrypt your data so you can regain access to your photos, notes, documents, device backups, and more. Data types that are protected by end-to-end encryption—such as your Keychain, Messages, Screen Time, and Health data—are not accessible via iCloud Data Recovery Service. Your device passcodes, which only you know, are required to decrypt and access them. Only you can access this information, and only on devices where you're signed in to iCloud. [1] https://support.apple.com/en-us/HT202303 https://support.apple.com/en-us/HT202303
al_borland 4y ago
>Currently you need remember to register at least 2 security keys, in case one is lost/misplaced. This is always my issue with 2FA or passwordless auth. You're forced to have 2 devices and are kind of screwed if you don't hvae two on you. I was on a trip and broke my iPhone. It had my plane tickets on it to get home. I was able to get a replacement from Apple, they just gave it to me and sent me on my way. When I turned it on it wanted me to authenticate with one of my other Apple devices. By dumb luck I happened to have my iPad with me. If I didn't have that, I'm not sure what I would have done. A co-worker told me to move all my 2FA to Authy as a means to avoid locking 2FA to hardware, but I haven't sufficently looked into it yet. While I don't like passwords and understand their very real security limitations. I'm also not a fan of my phone becoming my identity.
- lathiat 4y ago
  Your options are here btw. Another apple device, text to phone number or account recovery which is automated but takes a few days: https://support.apple.com/en-us/HT204915 https://support.apple.com/en-us/HT204915
- nicoburns 4y ago
  Password managers like Bitwarden can do TOTP with syncing. Doesn’t help with Apple though which uses non-standard 2FA. I actually have some accounts using SMS still, because I can fairly easily get a replacement sim if the device is lost.
- hoorible 4y ago
  Apple’s implementation uses SMS as a backup. Thinking is probably that if you only have one device, it’s usually your phone; so you would have been able get your 2FA code via text. It’s not easily discoverable though, so easy for you to miss it.
  - chrishas35 4y ago
    > Apple’s implementation uses SMS as a backup. I hope they'll go away from this, or at least give the option. I won't use their password/key storage until they do. 2FA is only as good as the weakest link, and SMS is the weakest possibility.
userbinator 4y ago
It's strange and rather unfortunate to see this constant reinvention of authentication methods. Asymmetric encryption as used in things like SSH keys and TLS client authentication have been around for decades, are very much standard, and the only changes to those have been stronger algorithms and longer keys. Smartcards as hardware secure elements have also been around for a long time. I'm not sure how much of a conspiracy theory it is to say that things like this are merely attempts by Big Tech to stronghandle everyone into their own idea of "standards" and run away from all the smaller players in the industry, but I'm sure that we had everything necessary for "passwordless authentication" two decades ago, or at least methods in which it's not necessary to send a password to the authenticating server nor store them there.
- smaudet 4y ago
  Its absolutely not a conspiracy theory, but it is a bit more complex than that there is was a coordinated push - there was a big push a while back from the likes of Microsoft to e.g. eradicate ssh credentials - in favor of stuff like AD (ugh, why?), specifically wrt to git clients. I know, GitHub still takes ssh (they'd break too many people otherwise), but places started moving towards AD, or "password manager integration" clients. Part of that is on the "security contractors", who are objectively snake-oil salesmen (when you make a living selling people publicly, freely available, publicly supported software, and charging 6 figures for it, that is the definition of a swindler), especially since they started propagating their whole "security regimen" as a set of tasteless, mostly useless "security awareness" trainings. They harped a lot on choosing good passwords, caused a lot of bad password security practices on almost every website (I still see this everywhere online - please use 10 characters with one symbol from (!$./ ... etc) and 1 number - no - use entropic password measurement and maybe don't assume your site is important enough to warrrant a high-entropy password). So, once we were all left with an unsustainable bag of crappy passwords for every buytoothpaste.com website out there... well we all had to try to invent something else. There was SSO OAuth, that failed because it was overcomplex (or got rolled into a banal corporate policy system which was horridly complex to deploy and the security contractors got paid to audit the bad systems). Then pile on the other heap of bad password strenghtening abstractions (2FA), etc., you get to today. We never had SSH for the browser, GPG/PGP remained meh, so the result is a constant stream of "new solutions" to a problem which could have been solved by a) Not caring as much about passwords, communicate risk to the users instead b) fixing ssl/ssh. And why did nobody do a) or b)? Again, I blame "security contractors" for a) and b) people not being paid to do it. Yeah, profit-seekers will always try to capitalize on chaos, that's hardly conspiracy, that's just business.
highwaylights 4y ago
Ok.. but hear me out here. What if the only computer (or even the only Apple computer) a user has is an iphone, and someone swipes it? Surely in that case you're now locked out of literally everything, no? Please explain to me why this is stupid because I'm certain someone thought of this very early on.
- andreasley 4y ago
  As mentioned, the Passkeys are synced in iCloud, so a lost device doesn't mean the credentials are lost. If you still can log in to iCloud, you're fine. If your Apple ID password has been changed, Apple provides a workflow to regain access to your Apple ID [1]. There's also a process for account recovery for situations where you can't access your Apple ID because of two-factor authentication [2]. [1] https://iforgot.apple.com https://iforgot.apple.com [2] https://support.apple.com/en-us/HT204921 https://support.apple.com/en-us/HT204921
dmm 4y ago
A lot of sites allow you to create backup codes that you can print out and use once instead of the security key.

by zxcvgm 4y ago

gsibble 4y ago

How will this work on Linux?

psanford 4y ago
FIDO usb devices just use the HID protocol so they work fine on linux. Chrome and Firefox both support them. I wrote a FIDO implementation that protects the signing key using the system's TPM specifically for linux: https://github.com/psanford/tpm-fido https://github.com/psanford/tpm-fido There is no reason why you couldn't implement a similar syncing strategy in a tool like this if you wanted to.
- balena 4y ago
  Isn't this approach significantly less secure than Apple's though? As far as I understand the secure enclave coprocessor in Apple devices stores key material and implements user verification (TouchID etc.), right? Instead software like tpm-fido bridges (in software) a user verification mechanism (maybe even a fingerprint reader) and the system's TPM. But such a system can be interposed with mere root access, and the TPM tricked in giving out its secrets, no? Please correct me if I'm getting it wrong, but Apple's approach is instead resistant even to full kernel compromise, precisely because the communication between TouchID/FaceID and the secure enclave cannot be interposed. I'm a tpm-fido user myself by the way, thank you psanford!
  - psanford 4y ago
    Yes, having the verification done by the secure enclave itself is more secure. The TPM spec does allow for direct integration with biometric devices, but I'm not aware of any general purpose computers that ship in this configuration. > TPM tricked in giving out its secrets To be clear, the key can never leave the TPM (with how tpm-fido is implemented). The threat is an attacker can perform an online attack by getting the TPM to sign messages it shouldn't. But you couldn't steal the key from the TPM and use it somewhere else. But it doesn't really matter for the Webauthn threat model. An attacker with root access can steal your browser sessions directly.
    - balena 4y ago
      > To be clear, the key can never leave the TPM (with how tpm-fido is implemented). Yep sorry you're right you wouldn't get the actual keys to use elsewhere, you can just use them as if you had them on the "compromised" device only, my bad. > But it doesn't really matter for the Webauthn threat model. An attacker with root access can steal your browser sessions directly. If you're using WebAuthn to authorize the emission of session tokens you're absolutely right, just get root and steal them from the browser :) but WebAuthn is more versatile than that. You could e.g. require a WebAuthn assertion to authorize a payment. In that case root access still doesn't help you with a secure enclave, but is sufficient to trick your server in believing the user has authorized the operation with tpm-fido, right? Again I absolutely don't mean to detract from tpm-fido, just pointing out that, very sadly, I don't think a TPM+fingerprint reader+software can really replace integrated solutions like Apple's secure enclave, or a yubikey, etc. In general unless I'm mistaken, it's not a tpm-fido shortcoming specifically.
      - psanford 4y ago
        I agree that the secure enclave with integrated touch id is more secure. However, if your threat model is an attacker has root on your system, the secure enclave isn't going to protect you from much.
      - mwwaters 4y ago
        A compromised main UI device could also show the wrong account recipient, even if hardware key is used. The text could be changed on the screen when the user meant to send a small payment to someone else. Yubikey will be pressed like usual. Apple's standard prompt on the phone may not have the recipient shown.
- tialaramex 4y ago
  > just use the HID protocol This is literally true, and covers what was important in context, but warrants a little extra explanation. Since these devices are specifically for humans to interface with (they typically have a button or contact sensor, though some have keypads or a fingerprint reader) they are logically Human Interface Device class USB devices, but they do not speak the HID Keyboard or Pointing Device sub-protocols like your mouse or keyboard (or the built-in "take a photo" button on your web cam). Instead they provide a FIDO-specific HID sub-protocol, which is publicly documented, instead of operations like "Caps Lock pressed" it's got stuff like "Begin enrolment" or "PIN xxxx entered by the user" which only makes sense for this specific problem.
  - ptman 4y ago
    some yubikey modes of operation do emulate keyboards and paste a string of characters in text fields or terminals
    - tialaramex 4y ago
      They do, and an earlier version of my post mentioned that but I edited it down. However, FIDO mode does not speak the keyboard sub-protocol. This means on the one hand it's not useable out of the box with some random device that allows USB keyboard input like the custom Yubico OTP mode is, but on the other hand it's able to deliver a good UX while having excellent security properties that would not be practical using keyboard emulation.
  - _ea1k 4y ago
    Oh, thanks for the explanation. I guess this new protocol is why I don't see as many tokens randomly appearing in chat sessions these days.
- tkanarsky 4y ago
  Oh dang, thanks for writing tpm-fido! It works really well for my use case -- avoiding mandatory and incredibly annoying Duo Mobile 2fa on my school's website -- although I tore the presence verification out of the code for my purposes :) iirc, this relies on the uhid module to mock a physical fido2 key, and I'm not sure if there's a way to present a mock fido2 key OS-wide without relying on a virtual USB device. This was a bit of an issue when I tried setting up a similar fido2 emulator in a container, as the Google container OS doesn't allow loading kernel modules. Do you know if that's still the case, or if there's a way to mock a fido2 key systemwide without uhid?
  - psanford 4y ago
    > there's a way to mock a fido2 key systemwide without uhid? On Linux, Chrome and Firefox interface directly with the USB and Bluetooth interfaces. There is no OS level abstraction for FIDO devices on Linux.
- raxxorraxor 4y ago
  Is there a software implementation that would work without a TPM module where I can generate the keys myself?
  - psanford 4y ago
    Check out rust-u2f/softu2f[0]. [0]: https://github.com/danstiner/rust-u2f https://github.com/danstiner/rust-u2f

Vladimof 4y ago

> The syncing of passkeys in iCloud solves this backup problem. But then apple has your keys....

jtokoph 4y ago
I would assume that they are at least encrypted locally before being uploaded to iCloud. (But yes, Apple could always change things)
- SamuelAdams 4y ago
  Don’t be so certain - we need more details from Apple on this. Last I checked iMessage was still (!) not encrypted when backed up to iCloud. https://www.howtogeek.com/710509/apples-imessage-is-secure...-unless-you-have-icloud-enabled/ https://www.howtogeek.com/710509/apples-imessage-is-secure.....
  - judge2020 4y ago
    iCloud Keychain is end-to-end encrypted, Messages isn't because Apple took the tradeoff of allowing people to keep their imessage history even upon a support-initiated account reset, which otherwise will wipe your entire iCloud Keychain.
    - reshlo 4y ago
      Messages is end-to-end encrypted. The key is stored in iCloud backups if they’re enabled (and if I recall correctly the messages on your device are backed up as part of an iCloud backup as well), but you can turn those backups off. > [1]For Messages in iCloud, if you have iCloud Backup turned on, your backup includes a copy of the key protecting your messages. This ensures you can recover your messages if you lose access to your Keychain and your trusted devices. When you turn off iCloud Backup, a new key is generated on your device to protect future messages and isn't stored by Apple. > If you forget your password or device passcode, iCloud Data Recovery Service can help you decrypt your data so you can regain access to your photos, notes, documents, device backups, and more. Data types that are protected by end-to-end encryption—such as your Keychain, Messages, Screen Time, and Health data—are not accessible via iCloud Data Recovery Service. Your device passcodes, which only you know, are required to decrypt and access them. Only you can access this information, and only on devices where you're signed in to iCloud. [1] https://support.apple.com/en-us/HT202303 https://support.apple.com/en-us/HT202303

al_borland 4y ago

>Currently you need remember to register at least 2 security keys, in case one is lost/misplaced. This is always my issue with 2FA or passwordless auth. You're forced to have 2 devices and are kind of screwed if you don't hvae two on you. I was on a trip and broke my iPhone. It had my plane tickets on it to get home. I was able to get a replacement from Apple, they just gave it to me and sent me on my way. When I turned it on it wanted me to authenticate with one of my other Apple devices. By dumb luck I happened to have my iPad with me. If I didn't have that, I'm not sure what I would have done. A co-worker told me to move all my 2FA to Authy as a means to avoid locking 2FA to hardware, but I haven't sufficently looked into it yet. While I don't like passwords and understand their very real security limitations. I'm also not a fan of my phone becoming my identity.

lathiat 4y ago
Your options are here btw. Another apple device, text to phone number or account recovery which is automated but takes a few days: https://support.apple.com/en-us/HT204915 https://support.apple.com/en-us/HT204915
nicoburns 4y ago
Password managers like Bitwarden can do TOTP with syncing. Doesn’t help with Apple though which uses non-standard 2FA. I actually have some accounts using SMS still, because I can fairly easily get a replacement sim if the device is lost.
hoorible 4y ago
Apple’s implementation uses SMS as a backup. Thinking is probably that if you only have one device, it’s usually your phone; so you would have been able get your 2FA code via text. It’s not easily discoverable though, so easy for you to miss it.
- chrishas35 4y ago
  > Apple’s implementation uses SMS as a backup. I hope they'll go away from this, or at least give the option. I won't use their password/key storage until they do. 2FA is only as good as the weakest link, and SMS is the weakest possibility.

userbinator 4y ago

It's strange and rather unfortunate to see this constant reinvention of authentication methods. Asymmetric encryption as used in things like SSH keys and TLS client authentication have been around for decades, are very much standard, and the only changes to those have been stronger algorithms and longer keys. Smartcards as hardware secure elements have also been around for a long time. I'm not sure how much of a conspiracy theory it is to say that things like this are merely attempts by Big Tech to stronghandle everyone into their own idea of "standards" and run away from all the smaller players in the industry, but I'm sure that we had everything necessary for "passwordless authentication" two decades ago, or at least methods in which it's not necessary to send a password to the authenticating server nor store them there.

smaudet 4y ago
Its absolutely not a conspiracy theory, but it is a bit more complex than that there is was a coordinated push - there was a big push a while back from the likes of Microsoft to e.g. eradicate ssh credentials - in favor of stuff like AD (ugh, why?), specifically wrt to git clients. I know, GitHub still takes ssh (they'd break too many people otherwise), but places started moving towards AD, or "password manager integration" clients. Part of that is on the "security contractors", who are objectively snake-oil salesmen (when you make a living selling people publicly, freely available, publicly supported software, and charging 6 figures for it, that is the definition of a swindler), especially since they started propagating their whole "security regimen" as a set of tasteless, mostly useless "security awareness" trainings. They harped a lot on choosing good passwords, caused a lot of bad password security practices on almost every website (I still see this everywhere online - please use 10 characters with one symbol from (!$./ ... etc) and 1 number - no - use entropic password measurement and maybe don't assume your site is important enough to warrrant a high-entropy password). So, once we were all left with an unsustainable bag of crappy passwords for every buytoothpaste.com website out there... well we all had to try to invent something else. There was SSO OAuth, that failed because it was overcomplex (or got rolled into a banal corporate policy system which was horridly complex to deploy and the security contractors got paid to audit the bad systems). Then pile on the other heap of bad password strenghtening abstractions (2FA), etc., you get to today. We never had SSH for the browser, GPG/PGP remained meh, so the result is a constant stream of "new solutions" to a problem which could have been solved by a) Not caring as much about passwords, communicate risk to the users instead b) fixing ssl/ssh. And why did nobody do a) or b)? Again, I blame "security contractors" for a) and b) people not being paid to do it. Yeah, profit-seekers will always try to capitalize on chaos, that's hardly conspiracy, that's just business.

highwaylights 4y ago

Ok.. but hear me out here. What if the only computer (or even the only Apple computer) a user has is an iphone, and someone swipes it? Surely in that case you're now locked out of literally everything, no? Please explain to me why this is stupid because I'm certain someone thought of this very early on.

andreasley 4y ago
As mentioned, the Passkeys are synced in iCloud, so a lost device doesn't mean the credentials are lost. If you still can log in to iCloud, you're fine. If your Apple ID password has been changed, Apple provides a workflow to regain access to your Apple ID [1]. There's also a process for account recovery for situations where you can't access your Apple ID because of two-factor authentication [2]. [1] https://iforgot.apple.com https://iforgot.apple.com [2] https://support.apple.com/en-us/HT204921 https://support.apple.com/en-us/HT204921

dmm 4y ago

A lot of sites allow you to create backup codes that you can print out and use once instead of the security key.