3 ms·

> 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

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

cyphar 4y ago
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.
0xCMP 4y ago
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.
- prophesi 4y ago
  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.
  - lxgr 4y ago
    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.
  - afavour 4y ago
    Isn’t tying specifically to a device and biometrics the point?
    - josteink 4y ago
      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.
      - danShumway 4y ago
        > 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.
      - 0xCMP 4y ago
        > 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.
- kps 4y ago
  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.
  - lxgr 4y ago
    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.
    - kps 4y ago
      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.
      - lxgr 4y ago
        > 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-protocol-extension-to-simplify-backup-security-keys/ 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.
rgoulter 4y ago
> 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 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"
lumb63 4y ago
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.

cyphar 4y ago

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.

0xCMP 4y ago

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.

prophesi 4y ago
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.
- lxgr 4y ago
  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.
- afavour 4y ago
  Isn’t tying specifically to a device and biometrics the point?
  - josteink 4y ago
    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.
    - danShumway 4y ago
      > 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.
    - 0xCMP 4y ago
      > 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.
kps 4y ago
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.
- lxgr 4y ago
  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.
  - kps 4y ago
    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.
    - lxgr 4y ago
      > 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-protocol-extension-to-simplify-backup-security-keys/ 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.

rgoulter 4y ago

> 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 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"

lumb63 4y ago

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.