4 ms·
> Unfortunately at the moment it seems like I either have a cloud sync vendor lock-in or a single point of failure, or I have the completely impractical solutio
by tzs 1y ago
> Unfortunately at the moment it seems like I either have a cloud sync vendor lock-in or a single point of failure, or I have the completely impractical solution of enrolling multiple devices, which means I have to carry both around with me, thus making it far more likely I lose both of them!
• You can use multiple independent cloud sync vendors. When I add passkeys to an account I add two passkeys. One gets stored in 1Password and synced using their cloud. The other gets stored in Apple's Password and synced using Apple's cloud. This should give you enough redundancy to mitigate most vendor lock-in concerns.
• If using devices that don't cloud sync I don't see why your would need to carry around two devices in order to enroll two devices. Carry around one device, and when you make a new account create a passkey for that account stored in the device.
Later, back home, login into any accounts you created while away using the passkeys on the device you were carrying, and create a second passkey on each of those accounts and store it on the other device.
- rcxdude 1y agoManually enrolling multiple devices/apps is pretty much the main thing that I view as impractical (especially because I need a system that can handle a range of authentication options: not everything supports passkeys, some passkey implementations prevent enrolling multiple devices, and that's the standard for TOTP as well). I have a lot of accounts, and it's really not something I can manage reliably to make sure that two different systems are in sync. The thing is, this seems like an entirely solvable problem, from multiple angles: e.g. an end-to-end encrypted sync between devices (using some pairing process), or, even better, a way to enroll a non-present device as an alternative (though this has some of its own challenges, if not just using a persistent certificate). It suprises me a little that there's nothing that really attempts to address this.
- tzs 1y ago> The thing is, this seems like an entirely solvable problem, from multiple angles: e.g. an end-to-end encrypted sync between devices (using some pairing process), or, even better, a way to enroll a non-present device as an alternative (though this has some of its own challenges, if not just using a persistent certificate). It suprises me a little that there's nothing that really attempts to address this Apple is adding that in iOS 26 and MacOS 26 [1], based on the FIDO specification for this [2]. Google is also in the midst of implementing it [3]. [1] https://fidoalliance.org/9to5mac-apple-work-passkey-portability-is-finally-here-in-ios-26-and-macos-tahoe-26/ https://fidoalliance.org/9to5mac-apple-work-passkey-portabil... [2] https://fidoalliance.org/specifications-credential-exchange-specifications/ https://fidoalliance.org/specifications-credential-exchange-... [3] https://fidoalliance.org/mobileidworld-google-developing-passkey-transfer-feature-for-android-password-manager/ https://fidoalliance.org/mobileidworld-google-developing-pas...