Exactly. Planning for emergencies is a big factor in password/secret management.
Currently, managing and using close to a 1,000 passwords, all around 35 characters and completely random, is an absolute breeze using 1Password (and likely any password manager of choice) and my data is securely stored in a cloud I can access from any device (and from my neighbor's laptop if disaster should strike).
No way that I am handing over this functionality to a bunch of private keys that I can only access when logged in using a device from one specific vendor.
The security benefits are vastly less than the loss in portability/emergency use.
So the idea of passkeys is fantastic, but as long as I cannot store them in a central platform agnostic place, it's passwords for me.
No. That would be like having a steel door in your house, and a cardboard one next to it.
I believe the login flow on another device (let’s say a Windows laptop) is that you scan some QR code on the laptop’s screen from your iPhone. Then the iPhone communicates with the site and validates the passkey. And if that is all OK the site on the laptop will proceed to log you in.
> FIDO’s current proposal has no mechanism for bulk-transferring passkeys between ecosystems. If you want to switch from an Android phone to an iPhone—or vice versa—you won’t be able to easily move all your passkeys over.
Allowing each tenant to move thousands of highly-sensitive internal tokens to a competitor is something the credit card processing industry, somewhat surprisingly, has more or less solved. Most credit card gateways that store card information on file in a PCI compliant way will allow a merchant to specify another competing PCI compliant service provider, and will export the merchant's information directly to the new service provider in bulk, without needing to provide any of the raw information to the merchant themself.
Via
https://www.chargebee.com/blog/credit-card-portability-impor... it seems Braintree developed an industry standard for this in ~2010, potentially (I don't know the history) as a way to force Stripe to allow its merchants to move elsewhere in the ecosystem without holding their cards-on-file hostage. Based on the list at https://docs.spreedly.com/guides/exporting/ - all of whom support this workflow - it seems this was quite successful.
Its guiding light was to be "patterned after telephone number portability that was part of the 1996 Telecommunications Act" - which is quite telling in this context.
Point is, there is precedent for developing frameworks in which secure token storage platforms can allow you to freely move between them, with secure bulk data transfers. Apple and Google would do well to get ahead of this, lest it become a regulatory or PR nightmare later when high-profile stories accuse them of intentionally promoting lock-in.
There isn’t really a standard beyond processors publish an OpenPGP and you negotiate over support tickets to determine where an encrypted file can be delivered.
There is no standard for the file format used to exchange data. Could be JSON, CSV, Excel, etc.
> a regulatory or PR nightmare later when high-profile stories accuse them of intentionally promoting lock-in.
Aren't there lots of instances of intentionally promoting lock-in on these platforms already? I haven't seen significant measures taken against that. How would this be different?
Not only the transfer issue, there is no way to have the root source of truth be yourself or your corp for corp owned devices, or dealing with mud puddle issues combined with an inability to have proper off device backups. You bring it up in tech talks about it and they sputter and avoid answering it.
Currently, managing and using close to a 1,000 passwords, all around 35 characters and completely random, is an absolute breeze using 1Password (and likely any password manager of choice) and my data is securely stored in a cloud I can access from any device (and from my neighbor's laptop if disaster should strike).
No way that I am handing over this functionality to a bunch of private keys that I can only access when logged in using a device from one specific vendor.
The security benefits are vastly less than the loss in portability/emergency use.
So the idea of passkeys is fantastic, but as long as I cannot store them in a central platform agnostic place, it's passwords for me.