12 ms·

What do you mean by real backups? What's stopping you from backing up your keys? Its up to the passkey "provider" to allow passkeys backup/sync.

politelemon 1y ago
Not really, they have no incentive to provide such a thing nor is it mandatory for them to do so.
- stavros 1y ago
  Are you saying password managers don't have an incentive to provide a feature users want? That describes literally their entire featureset.
  - anonymars 1y ago
    What incentive do they have to make it easy to migrate to a different provider?
    - stavros 1y ago
      People want the ability to back their passkeys up. The fact that this can be used for migrating is an unfortunate side-effect, as far as the provider is concerned.
reginald78 1y ago
Well, having your passkey provider blocked for doing that might stop you. https://github.com/keepassxreboot/keepassxc/issues/10407 https://github.com/keepassxreboot/keepassxc/issues/10407 Of course, they might just block you for not being on a whitelist of approved providers anyway.
- eddythompson80 1y ago
  That's such a strawman argument. Read the link you pasted again
  - anonymars 1y ago
    Strawman? We are talking about this link, right, the one that says: > I've already heard rumblings that KeepassXC is likely to be featured in a few industry presentations that highlight security challenges with passkey providers, the need for functional and security certification, and the lack of identifying passkey provider attestation (which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations). > The reason we're having a conversation about providers being blocked is because the FIDO Alliance is considering extending attestation to cover roaming keys. > From this conversation it sounds like the FIDO Alliance is leaning towards making it possible for services to block roaming keys from specific providers.
    - eddythompson80 1y ago
      Yes, read the quotes you took again. Attestation is not a thing currently. There is legitimate discussion about how to handle shitty password managers. If LastPass shits the bed again, it would be great to have a mechanism for others to block it or at least know that due to a major incident, keys from that tool are week. Debian OpenSSL keys were vulnerable for a long time and being able to know and alert or block private keys generated on a Debian machine is reasonable if not desirable. If KeepassXC is insecure or promote insecure practices who's fault is that and what do you suggest we do? The entire issue is about doing the minimum possible of not exporting it in plaintext. Nothing is stopping you from decrypting it and posting it on your Twitter if you so wish. Just don't have the password manager encourage bad practices. How it that unreasonable?
      - reginald78 1y ago
        Yes, we've seen you repeat that we have to read it again. I reread this morning before the post, but really just found more things supporting my position. > To be very honest here, you risk having KeePassXC blocked by relying parties (similar to #10406). From the linked https://github.com/keepassxreboot/keepassxc/issues/10406 https://github.com/keepassxreboot/keepassxc/issues/10406 > | no signed stamp of approval from on high > see above. Once certification and attestation goes live, there will be a minimum functional and security bar for providers. > | RP's blocking arbitrary AAGUIDs doesn't seem like a thing that's going to happen or that can even make a difference > It does happen and will continue to happen because of non-spec compliant implementations and authenticators with poor security posture. Is your argument that despite being doused with gasoline I can't complain because I'm not currently on fire?
- tzs 1y ago
  The objection there was not to providing passkey backup. It was to doing it in plain text.
- timmyc123 1y ago
  Since you keep posting this link, I'll just keep saying it: there is no credential manager attestation in the consumer synced passkey ecosystem. Period. There is no way to build and allowlist, by design. The consumer synced passkey ecosystem is open.

politelemon 1y ago

Not really, they have no incentive to provide such a thing nor is it mandatory for them to do so.

stavros 1y ago
Are you saying password managers don't have an incentive to provide a feature users want? That describes literally their entire featureset.
- anonymars 1y ago
  What incentive do they have to make it easy to migrate to a different provider?
  - stavros 1y ago
    People want the ability to back their passkeys up. The fact that this can be used for migrating is an unfortunate side-effect, as far as the provider is concerned.

reginald78 1y ago

Well, having your passkey provider blocked for doing that might stop you. https://github.com/keepassxreboot/keepassxc/issues/10407 https://github.com/keepassxreboot/keepassxc/issues/10407 Of course, they might just block you for not being on a whitelist of approved providers anyway.

eddythompson80 1y ago
That's such a strawman argument. Read the link you pasted again
- anonymars 1y ago
  Strawman? We are talking about this link, right, the one that says: > I've already heard rumblings that KeepassXC is likely to be featured in a few industry presentations that highlight security challenges with passkey providers, the need for functional and security certification, and the lack of identifying passkey provider attestation (which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations). > The reason we're having a conversation about providers being blocked is because the FIDO Alliance is considering extending attestation to cover roaming keys. > From this conversation it sounds like the FIDO Alliance is leaning towards making it possible for services to block roaming keys from specific providers.
  - eddythompson80 1y ago
    Yes, read the quotes you took again. Attestation is not a thing currently. There is legitimate discussion about how to handle shitty password managers. If LastPass shits the bed again, it would be great to have a mechanism for others to block it or at least know that due to a major incident, keys from that tool are week. Debian OpenSSL keys were vulnerable for a long time and being able to know and alert or block private keys generated on a Debian machine is reasonable if not desirable. If KeepassXC is insecure or promote insecure practices who's fault is that and what do you suggest we do? The entire issue is about doing the minimum possible of not exporting it in plaintext. Nothing is stopping you from decrypting it and posting it on your Twitter if you so wish. Just don't have the password manager encourage bad practices. How it that unreasonable?
    - reginald78 1y ago
      Yes, we've seen you repeat that we have to read it again. I reread this morning before the post, but really just found more things supporting my position. > To be very honest here, you risk having KeePassXC blocked by relying parties (similar to #10406). From the linked https://github.com/keepassxreboot/keepassxc/issues/10406 https://github.com/keepassxreboot/keepassxc/issues/10406 > | no signed stamp of approval from on high > see above. Once certification and attestation goes live, there will be a minimum functional and security bar for providers. > | RP's blocking arbitrary AAGUIDs doesn't seem like a thing that's going to happen or that can even make a difference > It does happen and will continue to happen because of non-spec compliant implementations and authenticators with poor security posture. Is your argument that despite being doused with gasoline I can't complain because I'm not currently on fire?
tzs 1y ago
The objection there was not to providing passkey backup. It was to doing it in plain text.
timmyc123 1y ago
Since you keep posting this link, I'll just keep saying it: there is no credential manager attestation in the consumer synced passkey ecosystem. Period. There is no way to build and allowlist, by design. The consumer synced passkey ecosystem is open.