4 ms·

Plus many want your phone number or some random app by them on your phone for their 2FA (instead of e.g. TOTP that you contol), less secure because they now can

Plus many want your phone number or some random app by them on your phone for their 2FA (instead of e.g. TOTP that you contol), less secure because they now can leak your phone number or do something with an update to the app BTW what's the sentiment on passkeys?

account-5 2y ago
In my opinion passkeys, whilst solving the password related issues, introduce their own. The risk of losing access to your accounts is greater if you tie everything to one device and that's lost or stolen, and the "solution" to use more than one device is not a solution, or feasible for everyone. There's also the risk of vendor lock-in, which is definitely an aim of the big providers like Apple, Google and Microsoft; which is a bigger risk to those less tech savvy.
- dcow 2y ago
  FWIW no consumer implementation of passkeys is device bound for exactly this reason. The threat of a user losing a device is much bigger and pressing than getting phished. All passkeys are backed up in a sync fabric.
  - gclawes 2y ago
    You _can_ use a standalone YubiKey or similar dedicated hardware tokens as a passkey, but they have limited slots for discoverable credentials. But yeah, anything resembling a phone passkey seems to have a sync fabric behind it.
  - jampekka 2y ago
    Most consumer passkey implementations are lock-in. https://arstechnica.com/security/2024/12/passkey-technology-is-elegant-but-its-most-definitely-not-usable-security/ https://arstechnica.com/security/2024/12/passkey-technology-...
    - reginald78 2y ago
      And one of the developers of passkeys threatened to use the specified attestation anti-feature to blackball Keepassxc's implementation when they made something not locked in enough. https://github.com/keepassxreboot/keepassxc/issues/10407 https://github.com/keepassxreboot/keepassxc/issues/10407 There have been some discussions to create an export standard since then but I remain skeptical. Why was this not part of the original spec but the ban hammer was? Depending upon how this standard is implemented I can easily see it preventing export to anything but Google, Microsoft and Apple's implementations. And it still leaves the attestation badness in place.
      - dcow 2y ago
        I was referring to device bound discoverable credentials and saying all implementations that an average Joe will run across have a sync fabric deliberately. Platform lock-in is a different thing. AFAIU the attestation referred to here won’t be signed so any implementation can say anything. It’s just supposed to be ise for things like showing the user a logo so they know where their passkey is stored.
    - dcow 2y ago
      Platform/vendor lock-in != device bound
red369 2y ago
Something I don't see talked about often regarding passkeys, is that they seem to be useful in addition to other methods, not instead. I've been thinking that they allow you to have long, non-memorisable unique passwords for an account (1), and then add passkeys on the devices you use often. The long, non-memorisable password isn't inconvenient because you don't need to use it, and the passkeys which are used day to day are resistant to phishing & keyloggers (as I understand). However, I don't know if that is how they're being used or marketed. 1) Perhaps even 2FA too, which wouldn't be as inconvenient if it's only used rarely. Given the points raised in this article, I'm rethinking whether that is necessary.

account-5 2y ago

In my opinion passkeys, whilst solving the password related issues, introduce their own. The risk of losing access to your accounts is greater if you tie everything to one device and that's lost or stolen, and the "solution" to use more than one device is not a solution, or feasible for everyone. There's also the risk of vendor lock-in, which is definitely an aim of the big providers like Apple, Google and Microsoft; which is a bigger risk to those less tech savvy.

dcow 2y ago
FWIW no consumer implementation of passkeys is device bound for exactly this reason. The threat of a user losing a device is much bigger and pressing than getting phished. All passkeys are backed up in a sync fabric.
- gclawes 2y ago
  You _can_ use a standalone YubiKey or similar dedicated hardware tokens as a passkey, but they have limited slots for discoverable credentials. But yeah, anything resembling a phone passkey seems to have a sync fabric behind it.
- jampekka 2y ago
  Most consumer passkey implementations are lock-in. https://arstechnica.com/security/2024/12/passkey-technology-is-elegant-but-its-most-definitely-not-usable-security/ https://arstechnica.com/security/2024/12/passkey-technology-...
  - reginald78 2y ago
    And one of the developers of passkeys threatened to use the specified attestation anti-feature to blackball Keepassxc's implementation when they made something not locked in enough. https://github.com/keepassxreboot/keepassxc/issues/10407 https://github.com/keepassxreboot/keepassxc/issues/10407 There have been some discussions to create an export standard since then but I remain skeptical. Why was this not part of the original spec but the ban hammer was? Depending upon how this standard is implemented I can easily see it preventing export to anything but Google, Microsoft and Apple's implementations. And it still leaves the attestation badness in place.
    - dcow 2y ago
      I was referring to device bound discoverable credentials and saying all implementations that an average Joe will run across have a sync fabric deliberately. Platform lock-in is a different thing. AFAIU the attestation referred to here won’t be signed so any implementation can say anything. It’s just supposed to be ise for things like showing the user a logo so they know where their passkey is stored.
  - dcow 2y ago
    Platform/vendor lock-in != device bound

red369 2y ago

Something I don't see talked about often regarding passkeys, is that they seem to be useful in addition to other methods, not instead. I've been thinking that they allow you to have long, non-memorisable unique passwords for an account (1), and then add passkeys on the devices you use often. The long, non-memorisable password isn't inconvenient because you don't need to use it, and the passkeys which are used day to day are resistant to phishing & keyloggers (as I understand). However, I don't know if that is how they're being used or marketed. 1) Perhaps even 2FA too, which wouldn't be as inconvenient if it's only used rarely. Given the points raised in this article, I'm rethinking whether that is necessary.