5 ms·

If nothing else, it has more bits of security than a password has & so is less crackable. It's also an official standard that should integrate effortlessly int

If nothing else, it has more bits of security than a password has & so is less crackable. It's also an official standard that should integrate effortlessly into apps & websites alike. Password Managers are- as far as I know- all bespoke solutions with their own custom implementations. Not having a common interoperable framing for implementation & extension limits user's control & optionality. The other major advantage is that sites don't need to support "Passkey". They support Webauthn. Then the user can use what the user wants to use. If they want to use a hardware key, go for it. If they have a user agent that implements WebAuthn by carving their keys in a stone tablet & using computer vision to read the credentials back, they can use that. Standards enable flexibility which enables possibility.

alsdfjkslfheu 4y ago
> Standards enable flexibility which enables possibility. what?! standards are the opposite of flexible. by definition. here's something that is better than webauthn, published and battle tested since 2018, and nobody cares: https://hacks.mozilla.org/2018/11/firefox-sync-privacy/ https://hacks.mozilla.org/2018/11/firefox-sync-privacy/ it have all the advantages of webauthn, plus it is truly on-device, no middle man, you can easily recover keys simply by having more than one device... no server can read or data. only silly thing is that firefox insists on shipping with the auto-fill option enabled by default. only feature missing that this thread seems to brings up is support for external usb devices (which i personally don't care for, but is probably on the roadmap) -- i'm blocked from adding replies, so replying here: > it does passwords not keys well, that is what worked on 100% the internet in 2018 (and today, ha!). But it is a data store where you have full control. ironically this is what gives true flexibility, a well designed system with fully open source implementation and apis, not spec by ad vendors as claimed before. anyway, The existing browser implementation does passwords (and bookmarks!!!) but you can extend to be a distributed yubikey if you'd like. nothing is blocking you. as I said, it is something better than a hardware store, better than a cloud broker for your identity, etc... but nobody cares. And now that FIDO has marketing from the big Advertisers everyone wants it yesterday.
- tadfisher 4y ago
  Firefox syncs passwords, not keys. Passwords can be reused, stolen, or leaked, all of which cannot be done to WebAuthn keys.
  - crote 4y ago
    If I am not mistaken, all Passkeys implementations allow keys to be synced between multiple devices. This means it is by definition possible for them to be stolen or leaked. Webauthn keys are only secure against stealing & leaking if they are backed by a proper separate token like a Yubikey, but it seems the People That Be want us to get rid of those ASAP.
    - WorldMaker 4y ago
      To my understanding, Passkeys implementations don't sync private keys, they sync and cross-sign public keys. Some vendors may also add "recovery" public keys to those synced keychains so that you can "Forget Password" your way out of a lost device or locked account or bootstrap new devices, and you have to trust your chosen vendor's security for how they manage that private key for any "recovery" keys. But my impression is that there isn't anything that Passkeys is doing that you couldn't do by also collecting Yubikey public keys by hand and making your own keychains if you are sufficiently motivated.
      - SgtBastard 4y ago
        > To my understanding, Passkeys implementations don't sync private keys, they sync and cross-sign public keys. I haven't seen anything in the FIDO alliance or vendor (Apple, Google, MS) documentation to suggest that they're cross-signed public keys - can you point to some that I may have missed? The reason why I ask is on the face of it, it doesn't make sense to implement in this way: It would mean that each new device would have its own keypair per service and cross signed by at least one other trusted device. Which could be fine, but now each service needs to store n public key pairs (one per device) after validating that the new key has been signed by a known key. Then, when a new device is added to the Keychain (in apple's case), that device needs to generate m new keypairs for m services, have them cross-signed and then proactively registered for each service. It does make sense to implement it as the person you're replying to suggests, where a shared private key is shared over an authenticated, end-to-end encrypted process - with the corresponding weakness that if the authentication method for adding new devices to an existing Keychain is compromised, so are all passkeys. Hence the question.
gtirloni 4y ago
1Password has passkeys in beta.

alsdfjkslfheu 4y ago

> Standards enable flexibility which enables possibility. what?! standards are the opposite of flexible. by definition. here's something that is better than webauthn, published and battle tested since 2018, and nobody cares: https://hacks.mozilla.org/2018/11/firefox-sync-privacy/ https://hacks.mozilla.org/2018/11/firefox-sync-privacy/ it have all the advantages of webauthn, plus it is truly on-device, no middle man, you can easily recover keys simply by having more than one device... no server can read or data. only silly thing is that firefox insists on shipping with the auto-fill option enabled by default. only feature missing that this thread seems to brings up is support for external usb devices (which i personally don't care for, but is probably on the roadmap) -- i'm blocked from adding replies, so replying here: > it does passwords not keys well, that is what worked on 100% the internet in 2018 (and today, ha!). But it is a data store where you have full control. ironically this is what gives true flexibility, a well designed system with fully open source implementation and apis, not spec by ad vendors as claimed before. anyway, The existing browser implementation does passwords (and bookmarks!!!) but you can extend to be a distributed yubikey if you'd like. nothing is blocking you. as I said, it is something better than a hardware store, better than a cloud broker for your identity, etc... but nobody cares. And now that FIDO has marketing from the big Advertisers everyone wants it yesterday.

tadfisher 4y ago
Firefox syncs passwords, not keys. Passwords can be reused, stolen, or leaked, all of which cannot be done to WebAuthn keys.
- crote 4y ago
  If I am not mistaken, all Passkeys implementations allow keys to be synced between multiple devices. This means it is by definition possible for them to be stolen or leaked. Webauthn keys are only secure against stealing & leaking if they are backed by a proper separate token like a Yubikey, but it seems the People That Be want us to get rid of those ASAP.
  - WorldMaker 4y ago
    To my understanding, Passkeys implementations don't sync private keys, they sync and cross-sign public keys. Some vendors may also add "recovery" public keys to those synced keychains so that you can "Forget Password" your way out of a lost device or locked account or bootstrap new devices, and you have to trust your chosen vendor's security for how they manage that private key for any "recovery" keys. But my impression is that there isn't anything that Passkeys is doing that you couldn't do by also collecting Yubikey public keys by hand and making your own keychains if you are sufficiently motivated.
    - SgtBastard 4y ago
      > To my understanding, Passkeys implementations don't sync private keys, they sync and cross-sign public keys. I haven't seen anything in the FIDO alliance or vendor (Apple, Google, MS) documentation to suggest that they're cross-signed public keys - can you point to some that I may have missed? The reason why I ask is on the face of it, it doesn't make sense to implement in this way: It would mean that each new device would have its own keypair per service and cross signed by at least one other trusted device. Which could be fine, but now each service needs to store n public key pairs (one per device) after validating that the new key has been signed by a known key. Then, when a new device is added to the Keychain (in apple's case), that device needs to generate m new keypairs for m services, have them cross-signed and then proactively registered for each service. It does make sense to implement it as the person you're replying to suggests, where a shared private key is shared over an authenticated, end-to-end encrypted process - with the corresponding weakness that if the authentication method for adding new devices to an existing Keychain is compromised, so are all passkeys. Hence the question.

gtirloni 4y ago

1Password has passkeys in beta.