This is the concern, but exporting passkeys to other ecosystems seems like it'll come with time, even if via third-party tools or like how browsers will prompt you to "import your <passwords|passkeys>" upon setup.
"All your base are belong to us"
How so? I just created two passkeys for my Google account — one for Chrome, and one for my Apple Keychain.
theres a million ways to provide this functionality without relying on vendor lock in. they are pretty much working as a mini certificate authority/vendor.
instead of vetting clients and giving them CAs, they just run your credit card for some hardware or subscription, and validate your login.
Identity systems aren't too technically difficult, the challenge is properly rolling them out and getting mass adoption. Which means getting vendors/users on board. It's a problem solved by power and politics, not technological innovation.
Part of the difficulty of using secure credentials is sharing them between devices. It's easier to involve a third-party like Google who can do this for you. The big-tech doesn't actually want to solve the problem entirely because they want some form of control: Either locking you into their service, or aggregating the sites you log into, or both.
They also want your biometrics, and keep pushing the narrative that biometrics are for authentication, but biometrics should only represent identity, not authority.
What does "authority" mean here?
Biometrics are not it. Anyone can forcefully grab your finger and place it onto your phone screen. They can hold the phone up to your face.
Secure keys or passwords (actual authority) are only vulnerable to rubber-hose cryptanalysis, but you can use plausibly deniable measures to reduce the risk.
Both are bits of data stored in the body (including mind and pockets) that suggest the owner is giving consent.
They both have flaws, but what are the alternatives?
The mind provides authority.
Use both!
But don't mix them up.
I think a better solution for authentication is a combination of a cryptographic key or seed and a passphrase held in the mind. Keys could be provided by an NFC ring, which should be more difficult to lose or have stolen than a phone.
We have a lot to talk about and exchange information.
greg at the domain qbix.com
I regret to inform you that someone has carelessly or maliciously leaked your deobfuscated email address, on the site
You could say this about Google's proprietary authenticator app in the past, but now that they support Passkeys, arguably the opposite is true.
Importantly, you can now (with FIDO CTAP 2.2 and tunnel services [1]) use an out-of-platform Passkey to log into your account cross-device, e.g. you can use an iOS Passkey to log into an account on a Windows Chrome instance via QR/Bluetooth.
There's absolutely nothing stopping you from providing your own implementation as long as it complies with the "hybrid transports" part of FIDO CTAP 2.2.
[1] https://fidoalliance.org/specs/fido-v2.2-rd-20230321/fido-cl...
Does that not rather imply that, if I log in with faceid on an iphone, my login will be tied to my ability to faceid on an iphone, and hence only available on devices with faceid support?
As a user, that's sounding a lot like platform lock-in to me.
And as a developer, if I want a way for users to log in without a password, and I don't mind that login mechanism being reliant on the user's account with apple / google / microsoft - wouldn't I just add a 'log in with apple / google / microsoft' button to my login page?
I'll grant this proposal might also support the 0.01% of users who have a biometric yubikey - but those folks are sophisticated enough to operate a password manager so regular U2F will work just fine.
My government e-signature service does that: I can’t even use a Yubikey, ironically, because that’s not "FIDO level 2 certified". I had to buy a more or less completely unknown brand instead (of which a government affiliate is apparently the exclusive reseller in my country…)
Because sources like [1] say that "A passkey can replace a password and a second factor in a single step" and "a biometric sensor (such as a fingerprint or facial recognition), PIN, or pattern" - isn't there something in the standard that ensures the second factor is maintained?
If your site insists on the device providing a broad identifying signature (the specification says devices classes identified this way ought to consist of 10k+ devices, and in most cases a manufacturer will just identify particular models, like OK, this the model we made in 2019-2021, now we're re-tooling to make the newer model lets give it a new identifier) and the user agrees (I always refuse if asked, the documentation advises you just don't bother asking) to provide this, then you can see OK, it's a Yubikey Model 6J, I think that's (delete as appropriate) fine / not fine. This is obviously a large piece of extra maintenance work, hence it's advised you should not do it.
Importantly, I don't think there's a single implementation of Passkey that actually allows this. In theory you could move your keys but in practice, there is no way to transfer your private keys off of your phone.
There's also nothing in the spec that forces any provider to allow transfer, so I don't expect that to change any time soon. And even if you can transfer your keys (which you can't) there's also nothing in the spec other than "please don't do this" language that stops a site from using attestation to restrict sign-in from other devices that you've transferred your keys to.
It is very locked down right now.
The google password manager and Apple devices will sync private keys as part of the password manager sync fabric. They are on all devices.
In addition, the 'share password' option on Apple devices works with passkeys. To deter social engineering, the person needs to be in your contacts, and in proximity to receive an airdrop.
There's nothing (other than say future certification marks) to prevent software exporting via a CSV file, the same way many password managers export/import credentials today.
This is so deceptive -- you can not move a passkey "vault" from an Apple device to an Android device without doing a per-password operation. There are no Open implementations of a passkey authenticator and there is no standard format defined in the spec for how to do mass movement.
There are huge caveats to this that people are just glossing over and saying "yeah, they're portable, don't worry about it." It makes it really hard to trust passkey proponents when they talk about what's going to be supported in the future, because even the present support level is constantly being misrepresented. So how am I supposed to take their claims about what the future will look like if I can't trust them to talk about the present?
I mean, you bring up Airdrop. I feel like I need to check, is something changed and that now works on Android devices? I'd love to be wrong about this, but Apple's documentation doesn't mention airdropping a passkey to an Android device: https://support.apple.com/guide/iphone/share-passkeys-passwo...
That kind of platform lock-in seems like it would be an important caveat to mention when talking about backup. But I never see stuff like this mentioned.
I don't see how anyone could genuinely claim that passkey portability is exactly the same as an SSH key or password. That's just not true. Authenticating a second device per-site is not the same thing as a cross-platform backup.
> They are on all devices.
They're not on a Linux desktop. If you want to use passkey on a Linux desktop, your options are to authenticate through a secondary proprietary device or to use a Yubikey -- for all practical purposes a locked down device which can not be backed up (no, buying a second Yubikey and manually syncing them site-by-site is not the same as backup).
> There's nothing (other than say future certification marks) to prevent software exporting via a CSV file, the same way many password managers export/import credentials today.
And yet, none of them allow it. I keep getting told that nothing is preventing this, but... it's not supported.
And again, nothing in the spec requires it. This is asking for vendor lock-in. If it's not a big deal and everyone's going to support syncing across ecosystems, then it shouldn't be a big deal to add a standardized API for that to the requirements for being a certified provider.
I don't really see how this is different from the existing market of password managers, of which many have already announced plans or released products (e.g. Apple and Google) to add passkey support.
Is the worry going forward that _none_ of them will choose to support export/import or have documented vault formats?
> And yet, none of them allow it. I keep getting told that nothing is preventing this, but... it's not supported.
There also hasn't been anyone yet who has tried to define what that interchange format should be.
> And again, nothing in the spec requires it. This is asking for vendor lock-in.
There are a broad range of passkey providers, from open source hardware to FIPS certified solutions to solve government compliance requirements. Some of these would be very open to backup/restore, and might propose a format for doing so. For others it destroys their whole value proposition to their customers.
But those government agencies are specifically investing in that hardware because it _doesn't_ lock them into one vendor. Any other vendor who can meet their security requirements can sell into that space.
Do you really not see the difference here? Passwords are inherently resistant to vendor lock-in in a way that passkeys aren't. And honestly, not to call you out but we're back on this again:
> of which many have already announced plans or released products (e.g. Apple and Google) to add passkey support.
This is not representative of what the ecosystem actually looks like.
Apple and Google have announced zero plans beyond "we're looking into it" to allow open interchange with arbitrary 3rd-party clients. Chrome on Linux doesn't even support native passkeys at all. The most hopeful development I've seen in this space is Bitwarden. 1Password was billed as the solution, but I don't see any plans from 1Password to support porting to other password managers.
And any of these platforms blocking 3rd-party syncing is a big deal. If even just iOS decides "no, we won't allow that", that alone is a huge vendor lock-in that needs to be acknowledged.
So what plans can you point me towards where Google/iOS is announcing that they're going to build a generic API for exporting passkeys from the phone? And no, per-login adding another device isn't sync. We're glazing over this, but it's just not accurate to say that either iOS or Android are making serious progress towards portability. Their implementations are extremely locked down, and that's an important caveat that should be included in conversations about passkey portability.
> Is the worry going forward that _none_ of them will choose to support export/import or have documented vault formats?
My worry is that most of them won't, and that hardware attestation will get rid of the rest. Let's say there is a client that supports moving passkeys around. That still doesn't change the lock-in potential for all of the clients that don't, it doesn't mean users will be able to migrate to that client once they've been locked in. It doesn't mean that services won't block authentication using that client. A good standard should block this all off at the source; it should (to borrow from the Chromium dev team) encourage developers to fall into a "pit of success."
We already ran into this problem with 2FA codes on mobile devices. How long did it take Google Authenticator to support backup? That has impacts on the ecosystem beyond just "is it possible for someone who knows about the issue in advance to choose a client that's more open?"
> There also hasn't been anyone yet who has tried to define what that interchange format should be.
Isn't that kind of the job of a standard body? Is it actually unreasonable for me to ask the FIDO alliance to do that?
> Some of these would be very open to backup/restore, and might propose a format for doing so. For others it destroys their whole value proposition to their customers.
Maybe it would be OK for them to use something else then? We're building out an authentication format that not only has zero protections to prevent lock-in, but that includes tools to enforce lock-in (hardware attestation). And I can't help but think, maybe it's fine for the extremely limited pool of agencies that need to block backup/restore to have a custom solution that's different from what Netflix uses.
Again, going back to this philosophy of the "pit of success" it should be harder to lock a customer out of backup than it is support portability. Portability should be the default, and it should be work to make that go away. And that's a key difference with passwords. It is work to make a password unportable.
----
At the very least, the conversation we're having now is a lot different from "oh, you can move your passkeys off of your phone." You can't, not unless you're sticking with the same vendor.
I would be more amenable to these kinds of conversations about the challenges of supporting arbitrary sync/export/import if I didn't have to start each of these conversations by calling out that arbitrary sync/export/import doesn't already exist. Because you're right, there hasn't been anyone who "has tried to define what that interchange format should be." That interchange format doesn't exist right now.
I don't think it's accurate or helpful if someone asks, "is this portable yet" to say "yes" when there is no interchange format and 3rd-party sync is an entirely theoretical future capability that companies are looking into, and there's outright resistance to building 3rd-party sync into the spec. Give reasons why that portability doesn't exist yet, sure. Promise about what will exist in the future, sure. But don't just say, "yeah, we're portable, you can sync keys" when both Safari and Android have huge limitations on when and where keys can be synced.
I'm not privy to their priorities or timelines, no.
> And no, per-login adding another device isn't sync. It's just not accurate to say that either iOS or Android are making serious progress towards portability. Their implementations are extremely locked down, and that's an important caveat that should be included in conversations about passkey portability.
But other companies with a history of being open here also do not have the feature yet. I am equally non-privy to their priorities or timelines.
If you want to say "passkey implementations do not have a bulk export/import feature, which makes it time consuming to switch between implementations", that is 100% factual.
I would not qualify this as a "lock-in", any more a phone that needs to get its software reinstalled is "bricked". And I wouldn't take current state to imply some inherent permanent ecosystem-wide rejection of user backups and data portability, when many vendors have implementations that are still in beta.
> My worry is that most of them won't, and that hardware attestation will get rid of the rest.
There is a great deal of worry about hardware attestation even by the vendors you are likely most concerned about. Apple for example not only removed their attestation, but now anonymizes the authenticator via a zeroed AAGUID.
No matter the vendor, their users (and the overall ecosystem) will suffer if relying parties build allow lists of acceptable authenticators, and deny all others.
That said, I do suspect the ultimate goal is to have sites be able to tell if an authenticator can allow them to shortcut additional authentication checks or not. It could be those websites give a more complicated authentication process to passkeys which do not meet their physical factor requirement.
>> There also hasn't been anyone yet who has tried to define what that interchange format should be.
> Isn't that kind of the job of a standard body? Is it actually unreasonable for me to ask the FIDO alliance to do that?
Putting aside that I can't speak as to whether there is or is not an effort underway there -
It depends on the group, but proposed standards for interoperability typically need at least two implementations - two parties have to commit to actually supporting the result. Actual standards need to show way more.
If passkey providers hypothetically want an interoperable interchange format or protocol, they can try to standardize it in a number of places including under FIDO Alliance. Absolutely nothing prevents someone from creating their own bespoke backup/restore process in the meantime, which could very well get adopted by others.
> Maybe it would be OK for them to use something else then? We're building out an authentication format that not only has zero protections to prevent lock-in, but that includes tools to enforce lock-in (hardware attestation). And I can't help but think, maybe it's fine for the extremely limited pool of agencies that need to block backup/restore to have a custom solution that's different from what Netflix uses.
I don't think this fixes your overall concern. There's no technical measure to prevent implementations from limiting backup/restore even if you make all authenticators anonymous.
Likewise, I don't believe websites would choose "friendly" credentials over "strong" ones. They would let the system survive or fail based on the user feedback/complaints of "strong" mode.
> At the very least, the conversation we're having now is a lot different from "oh, you can move your passkeys off of your phone." You can't, not unless you're sticking with the same vendor.
Yes, the process is automated within the same ecosystem, and we (finally) have a way to use a phone to e.g. authenticate to a computer and cross ecosystems. So far there is no process to batch migrate.
There _is_ a manual process to migrate. I get your desires and your concerns about users not understanding that they will have this multi-device process for migration today. I'm personally hopeful that there will be a solution here eventually to streamline switching platforms and passkey managers, once someone prioritizes it.
How would they? None of the software involved here is Open Source, I can't open a pull request for any of this. And the backup/restore isn't going to work with any of the major players.
It's kind of striking that there literally isn't an Open Source provider supported on any of the major platforms. Let's say you build an Open Source one for Linux. Is it usable with Chrome? No, Google has no plans to support that. Does Mozilla have a working implementation? Also no.
Is that the FIDO Alliance's problem? Sort of? I mean, they want me to believe this is an Open standard. How many "Open" standards have zero officially sanctioned Open implementations of the standard?
> It depends on the group, but proposed standards for interoperability typically need at least two implementations - two parties have to commit to actually supporting the result. Actual standards need to show way more.
The FIDO Alliance has more than two members. Microsoft/Apple/Google are already in talks about how to build out passkeys. And they're the players that really matter here. Whatever standard they come up with (or decide not to come up with) is going to dictate how the rest of the ecosystem moves.
But again, they're the companies trying to tell me this is an Open replacement for passwords. I feel like it's kind of on them and their alliance to prove it.
We need to hold their feet to the fire and actively push people away from using passkeys until this problem is solved.
I guess this is where I'm at. Passkeys are a nice idea in theory, but the whole thing is too early in development to use or recommend to others at this point.
This is hopelessly naive.
We need to be actively making a lot of noise and sabotaging industry efforts to use passkeys until the respective vendors solve data portability.
I don't see any indication that Google is looking at Passkeys as just a faster way to log in without a password. They want to eventually replace passwords entirely.
My parents are a good example of this, they have recovery options set up so that we can get into their accounts if they die. None of those recovery options are compatible with current passkey implementations, and their phones might be the only computers they have that are capable of storing passkeys right now. I myself have exactly one device that's capable of acting as a passkey authenticator right now (my phone) and I suspect that'll stop working if I De-Google it and then I'll have zero usable authenticators. I'm not sure how I would add redundancy to a passkey login without buying additional hardware. It's not like my password vault where I can sync it to basically any computer or flash drive.
But that's a separate conversation. Regardless, the goal is the elimination of the password, a lot of coverage and advertising has centered around that. Passkey isn't in the long run designed to be supplemental to traditional log-in methods, it's intended to replace them.
The solution is to not use Apple's keychain for passkeys (and really not use Apple's proprietary services for anything at all), but we can't depend on people to have that foresight.
The authenticator is given a lot of leeway in how it does authentication. In the Apple platform case, it is "the user authentication on the device which is on the iCloud account and has set up iCloud Keychain".
So on my Mac I can use TouchID. On my phone I use FaceID. Both allow me to fall back to the device password (such as when I have the lid on my Mac closed).
Android will provide an API for that scenario (i.e. on-device third-party authenticators) in the near future [1].
Hopefully, iOS will do the same.
[1] https://developers.google.com/identity/passkeys/supported-en...
I can't rely on retaining access to my Google account for logging into things.
1Password has already announced their intention to use this once ready. I really hope iOS will provide something similar soon.
There's many implementations of OTP. I've never used google's and I've been fine.
Disclaimer: I own 2 NFC rings :)
https://developer.apple.com/passkeys/
https://arstechnica.com/information-technology/2022/10/passk...
Now I'm wondering what's the longest class name out there...
Take a look at this thread → https://news.ycombinator.com/item?id=4770861
Case in point → https://github.com/zxlooong/jdk16045/blob/master/com/sun/jav...
This is not what they want. They want to a) ensure passwords/accounts aren't being shared to ensure a single account is tied to a single user. They want this for all apps so they can recognize revenue for every user. b) They want more information on you as a user (as opposed to your family member on the same account). The wet dream is per-device, per-user profiles. Possibly even different [additional] costs for each attached device.
That is their goal. Big Tech all want this. That it increase friction to migrate is a side benefit (honestly not so much more than with passwords now). That it happens to benefit users is the lure to draw you in.
https://support.apple.com/en-gb/guide/iphone/iph0dd1796bb/16...
I don’t see any way that passkeys kill account sharing.
In fact, it's important that people do this so that the invalid concerns can be put to rest and (hopefully) the valid concerns can be mitigated.
To limit it to just one defeats the purpose of all this work. You really will only see that where there is a technical limitation (like... why does AWS only allow a single hardware key per user? If you setup SSO then you can have any number of keys)
> What I don't like bout Google doing this is that the big providers use this to tether and lock you in to their platform. The power of this shines when it's federated. So if you run a site, you can provide security to your users without them needing Google, FB, etc.
The value of many of these schemes is authenticating under your google/FB identity (email, phone number, org affiliations). It makes a lot of sense for centralized identity providers to do this because they already know who you are and how to authenticate you.
There is a growing untapped market for the authentication and secure use of of pseudonyms. For instance people that want to run a blog and interact in social media under a name that is not connected to their true name. Or some Senator wants to play video games but might be worried that it looks frivolous. This is a setting where something like MPK really shines. I believe over the next five years we will see an ecosystem around a pseudonymous web. MPK might have just been too early as that ecosystem isn't quite here yet.
So it should be easy for everyone else to do their own.
There are payment rings a plenty though, for just using them instead of contactless credit cards.
What I don't like bout Google doing this is that the big providers use this to tether and lock you in to their platform. The power of this shines when it's federated. So if you run a site, you can provide security to your users without them needing Google, FB, etc.