Amazon Passkeys Launched: Response to Consumer Demand with Poor Implementation
corbado.com
corbado.com
Which consumer base has demanded enhanced security and convenience (for which passkeys are the proclaimed answer)? The non-tech crowd has no idea what it is and is probably just hearing about it. The tech crowd on a forum like HN seems to be mostly against it because of issues with account recovery and cross-device use that passwords don’t pose.
From what I understand, it seems like passkeys may ultimately rely on SMS OTP or similar mechanisms for account recovery. The other likely result would be losing the account forever, especially if the user is a single device one (there are billions of such people around the world).
I’m going to wait it out a little longer to see how the interoperability factors play out in reality and learn from those who are braver than me.
What convenience? Amazon's implementation saves me exactly one thing. "Typing my password" (i.e. pressing my password manager's autofill key combination).
The annoying part is having to enter my OTP over and over and over again, with the non-functional "don't ask again on this browser" box below serving as a little mocking statement to show that they have indeed thought about this use case – they just haven't bothered to actually implement it.
Yeah it's going to be mostly the tech crowd at this point, and it will filter down to non-tech people. And we will all be better off when we are all using passkeys. Looking at my girlfriend's computer her password situation is a nightmare of potentially compromised passwords, reuse of weak passwords, among other issues. Even after spending hours trying to clean it up there are still tons.
If we were in a passkey only world then no more weak passwords for her to reuse, no chance of phishing said password from her. Even if the server gets hacked there is no password to get pwned.
I really don't care what the contingent of passkey haters on here say. A lot of the discourse here isn't what it used to be. Little better than Reddit for techies.
> From what I understand, it seems like passkeys may ultimately rely on SMS OTP or similar mechanisms for account recovery. The other likely result would be losing the account forever, especially if the user is a single device one (there are billions of such people around the world).
That's not as I understand it. Why would SMS OTP be used? 100% of accounts today will already have a password, that's how you would login if you lose your only passkey device.
If/When passwords are not a thing anymore then why wouldn't the recovery use a "lost password" type flow that happens is facilitated via the account email?
> I’m going to wait it out a little longer to see how the interoperability factors play out in reality and learn from those who are braver than me.
Fair enough, but you can add a passkey to an account and your password will still work. So it's not like it will cause any harm to try it. You can even remove passkeys from an account if you really don't want to use it.
The worst thing about passkey support on Amazon is they didn't embrace it completely so you still have to go through all of the login form bullshit instead of being a one step biometric unlock that passkeys can enable.
It's too bad, I'm really excited about passkeys increasing authentication usability (and security second, for me), but most people here seem to want to hold on to passwords, as if they aren't both terrible UX and terrible security.
But afaik the biggest implementation of passkeys (Apple) doesn't support attestation so right now it's not a problem, nobody requires it in order not to lose all the Apple userbase. This may change in the future though.
Another problem is no self hosted toolchain with full cross platform sync but hopefully it'll come.
The issue I have with attestation it that I feel that I feel that we're saying "is it a problem?" "no, but it theoretically could be, so let's use passwords instead".
I think that passkeys are better than passwords, even with attestation, and if it becomes a problem, we can complain about it then.
For example the admins at my work refuse to "certify" any security keys other than yubikeys. And because those do support attestation it is not possible to circumvent it. For work it's not an issue, they will just have to supply me a key if they want me to use the damn thing, but I don't want consumer-focused sites to use it obviously. Attestation is inherently evil and anti-FOSS.
I just won't opt in to it until attestation is gone, but thanks to iCloud not offering it, it is currently not demanded by any of the sites.
My main concern at this point is user confusion, followed by platform lock-in.
Or am I missing a way for users migrate from the Apple ecosystem to Google or vice versa, for example, without registering new passkeys for all of their accounts before they trade in their old device (or it breaks and they try to recover on another platform)?
Not even 1Password supports exportable passkeys at this point. Apple even lets me easily share them across accounts (which seems like a huge risk!), but obviously not across ecosystems either.
It's not that the arguments have been debunked, it's that advocates seem to almost purposefully misunderstand what people mean when they talk about attestation, portability, and account recovery. Registering multiple devices isn't portability. Keeping keys within a single ecosystem isn't portability.
Additionally, advocates ignore the current state of the ecosystem in favor of only talking about what the ecosystem is intended to be. A nontrivial number of services are using passkeys as a 2FA token. As a result, the current state of the ecosystem is that even ignoring the issue with providers, even websites themselves are not presenting a unified vision of what passkeys are intended to be. It borders on misinformation. No one is in alignment about what passkeys are, and multiple problems are being systematically ignored, and saying that the criticism is "debunked" isn't going to change that fact.
Is there a good web page that summarizes all this? Because I can't tell if I'm wrong or not with some of my questions.
I've been using passkeys on yahoo.co.jp for a while now after they prompted me to set it up.
It works fine on my Mac, but for whatever reason it won't see the passkey on my phone - it just pops up a QR code dialog and says to scan it on another device (my only other device is my Mac which won't scan QR codes). iCloud Keychain is syncing fine - regular passwords on other sites work.
Once that fails it drops back to SMS OTP. There is no option to log in with a password.
So as far as I see it, Passkeys are still an experimental technology. Passwords suck so I hope one day they figure out how to get it working.
In your case with your phone, I suspect that Yahoo has implemented some kind of device management and works with the WebAuthn request option AllowedCredentials to allow only certain credentials on a device (here probably something was messed up).
> If/When passwords are not a thing anymore then why wouldn't the recovery use a "lost password" type flow that happens is facilitated via the account email?
Well, passkeys are descended from FIDO/U2F keys, which have traditionally been used for "two factor authentication" - by confirming both 'something you have' and 'something you know' your account is protected if someone has shoulder-surfed your password, or stolen your phone, or hacked your e-mail, or whatever.
And FIDO/U2F keys kinda a hassle, so they're only used by the most security-conscious people in the most security-critical situations.
For these people, a recovery mechanism that falls back to a single factor (password-only login, e-mail only login) is a big weakness, security-wise.
I think what a lot of passkey advocates misunderstand is that this isn't a debate about what passkeys should look like once everyone has adopted them. It's a discussion about whether passkeys will ever get adopted.
Ordinary users are not going to use passkeys until these problems are solved. You're envisioning a world where everyone says, "there are tradeoffs, but we all made the switch and the security is better so tough luck." The reality is that fixing the tradeoffs are a precondition for passkeys to be a replacement for passwords.
The same industry that was incapable of teaching people how to use real 2FA tokens is not going to be able to teach them how to clone passkeys across devices. The discussion around passkey problems is not a discussion about how many people will grumble when passkeys eventually break into the mainstream. It is a discussion about whether passkeys are ever going to break into the mainstream at all.
----
Note that passkeys themselves are a response to this reality: it used to be that everyone talked about how cloud synchronization within an ecosystem was just too insecure and critics were going to have to get over the fact that it wasn't supported. This was a common debate on HN.
That changed, because it became obvious that passkeys were not going to happen without cloud sync and that roaming passkeys were a requirement, even if they made the standard slightly less secure. Now the same people are out saying that portability and better standardization among services is not the FIDO Alliance's problem to solve and people are just going to have to get over it.
And I don't think y'all understand how standards get adopted. Ordinary users are not going to get over it, they're going to refuse to use the standard. The first time they use passkeys and run into Amazon telling them that they can't log in from Firefox, they're going to walk away from passkeys forever.
If we continue to do this, don't we then still just have all the same problems with passwords?
Because of an embarrassing amount of ignorance. Own an android phone? An iPhone? Congratulations, your passkeys are on your password manager.
You can recover your passwords when you lose your phone right? Exact same mechanism. (Now, if we want to talk about how solid the protection is for apple/google at keeping these private keys safe in their clouds, and how secure something is when one magic password is enough to unlock literally everything, or how confident we can be that the govs won’t be able to get their paws on them, that’s a more nuanced topic).
With iCloud Keychain, you can keep your passwords (and other secure information) updated across your devices and shared with the people that you trust.
Proprietary keychain managers. I will not hand Google or Apple the keys for every account I have, or even just the metadata where I have accounts.
I'm well aware that they claim that they don't have access to that, but I do not trust them.
A passkey which is backupped to their Apple or Google accounts will make things easier.
Passkeys are complicated enough, but even as somebody having spent hours looking into WebAuthN and setting up my own smartcard-based NFC authenticator, it took me a while to understand what's going on with Amazon's implementation.
- "If you want to add a passkey, use a different cloud service account (example: Apple ID or Google account). Each cloud service account can only have one passkey for Amazon." is what I see in Firefox, for example – what on earth does that mean? Firefox doesn't synchronize passkeys with either of these accounts. The issue is that they don't support platform authenticators on macOS. That error message does not make sense!
- Ok, I get it now, so Firefox does not support passkeys, hence the button is greyed out, fair enough. But, wait... 1Password does provide passkey support through their Firefox extension. It works on every other WebAuthN/passkey-supporting site. And 1Password's passkeys do work on Amazon using Chrome! Do they just sniff the user agent here and grey out the button on Firefox? What's going on?
- The only option to manage passkeys in my Amazon account is to... delete ALL of them. I guess adding a list of passkeys and the dates they were added, like almost every other service I know supports, was just too much to ask from Amazon.
- "If you didn't set up this passkey, please go to your account settings to delete the passkey.". – Oh, right, let me quickly go through the literal dozens of options in my Amazon account page. I get that Amazon does not want to train users to click links from emails (although that ship has arguably sailed, which is why we are getting WebAuthN in the first place: It's phishing-resistant!). But Is it too much to ask to simply reference the path there, i.e. "Your Account -> Login & security -> Passkey" in that message?
On the other hand, this is completely in line with my user experience on any Amazon site or product. I wonder if Amazon is even aware of the mere concept of UI/UX design as something other than a half-day task any backend engineer is just expected to do as part of the feature they're shipping.
Assuming that this error message is correct and isn't just badly worded nonsense -- if the FIDO Alliance had any sense at all this would be barred from the spec and Amazon would have to either support correct behavior or skip getting certified and getting an official stamp of approval. I cannot believe that I'm being told by advocates that attestation for roaming providers won't be a problem when they can't even get websites to allow unlimited keys to be linked to an account.
"Websites wouldn't block an authenticator, they'd just be cutting off users", I am reassured while I watch Amazon sniff browser user agents so that it can block specific browsers from logging in. I'm glad that iOS is zeroing out authentication requests voluntarily, but if that error message is to be believed, that's apparently not good enough. It needs to be part of the spec.
Do you mean attestation? If so, I believe that’s mostly out of the picture already, since it does not even make any sense anymore with “cloud-resident” passkeys.
It can’t be what Amazon uses in any case, since I can use 1Password on Chrome, but not Firefox.
Correct, this is not attestation using the spec, but it is blocking off a device for logging into the service. To me, the relevance to attestation is that I'm just not confident that attestation "doesn't make any sense" for companies to pursue while I'm watching a service cut off a browser in a way that also doesn't make any sense for them to do.
I think if attestation doesn't make sense, it should be fine for the FIDO alliance to have as part of certification that any provider implementing the spec should be supported and that roaming passkey providers should all do what Apple is doing and refuse to identify themselves. That's kind of two separate things: roaming providers should refuse to identify themselves, and also services that are claiming to support passkeys should as part of spec implementation not be allowed to do things like cut off a login from a passkey provider either by relying on attestation or by implementing their own hacky solution and doing something like sniffing the user agent.
(Tangential) I keep saying this: if any other company without a business model as strong as Amazon was run like Amazon they'd be dead.
But for some reason execs see Amazon and think "if they can ship and utterly mediocre product and win, so can we"
My brother in Christ first build a distribution network that can deliver a million products to my place within 1 day, then you earn the right to ship an eyesore app.
It's a bit like reading a blog on cocacola.com — "People disappointed by Pepsi, say they prefer other soft drinks". Passkey integration is this company's main (only?) product, and the submitter to HN is the company co-founder.
I appreciate that the blog post itself wasn't overly sales-y, but maybe it'd be good to have a [Advertorial] tag or something for when people want to promote their own product. That, or have OPs do a disclosure in a comment if they're submitting something through a personal account that's on behalf of their own company.
1. Asking for OTP after using a passkey is redundant and annoying 2. Not listing the keys individually makes management hard - I can't remove a single Yubikey, or Windows Hello or my phone. If anything is replaced it will just keep accumulating in my account. It should list each passkey individually and allow me to give a name to each one.
I strongly prefer to keep each account independent, so that there's no single point of failure outside of myself.
All the bits and such to generate those passkeys originate on one device... And it's specifically designed for it's security, to not allow the key material be removable from that one device...
A device that may end up in the bottom of a canal in Venice...
It's then a case of how do you bootstrap back up to having access?
- Did you remember to spend money on an additional passkey device? - Did you ensure you don't need the passkey device you lost to access the other device which the passkey syncs with (for the iOS keychain/google whatever options) - Did you remember at each. and. every. account. you. have. to enroll both your primary and secondary passkeys?
vs.
- You can remember enough to get into email for resets, or there's a note or a thumb drive kept in a drawer that has enough password info (itself possibly password protected) to get you back on your digital feet.
I understand the need for not being able to export from a passkey device... but it massively shifts the paradigm of how users need to operate. And puts all the trust in devices.
All I miss now is the possibility to backup / sync the passkeys myself, without having to rely on Apple or Google or whatever.
So I thought you shouldn't need an additional passkey device or to remember anything special other than account recovery information.
Then, optionally/implementation specific(?), when you login with a new device for the first time, with that cloud/multi-device credential, some other shenanigans happen. [4](?)
[1] https://media.fidoalliance.org/wp-content/uploads/2022/03/Ho... [pages 5-7]
[2] https://www.w3.org/TR/webauthn-3/#backup-eligible
[3] https://support.apple.com/guide/iphone/passkeys-passwords-de...
[4] https://www.w3.org/TR/webauthn-3/#sctn-device-publickey-exte...
The fact that the other three links go to whitepapers and specs is part of the PR problem passkeys have. It's hard to parse for answers to simple questions.
Such as: what if I don't want to use Apple any longer and wish to move to another provider?
Ideally, this would be the point where the Alliance would step in and say, "okay clearly we need to standardize a lot more because y'all can't handle this much leeway in how you implement the standard." Ideally it would give the Alliance pause about other parts of the standard like attestation where they're also being painfully naive about how corporate implementations will go. But instead, the industry seems intent on barrelling forward with passkeys in their current state anyway.
Passkeys aren't ready to recommend to normal consumers yet. We still have yet to see any proof that the portability and lock-out problems are actually going to be addressed. Words are cheap, talk to me when there is an official spec for transferring passkeys between ecosystems and when adherence to that spec and allowing export is a requirement for certification. Talk to me when the services that allow only linking one passkey are barred from official certification until they fix the problem.
And people say fixes are coming, but nobody in the industry is waiting for them to come. It's not a priority for them. The major companies are showing that they are perfectly willing to recommend a product to consumers in a half-finished state at a point where there is literally no major implementation that allows transferring passkeys between ecosystems and where there serious caveats around linking passkeys to accounts. So what trust am I supposed to have in that? Don't tell me the FIDO Alliance cares about portability or ease of access; the companies involved do not consider lack of portability and access to be a blocker.
I consider it irresponsible to recommend passkeys in their current state and irresponsible for companies to be rolling out wide support based on the current state of the ecosystem. I've lost a ton of faith in the entire standard because of how advocates have glossed over issues and because of how the industry is currently showing that actual universal access and universal support and real Open implementations are not a requirement and that they're willing to try pushing consumers onto passkeys before those critical problems are fixed. The whole thing up to this point has felt dishonest and pushy and weird.
If the intent from advocates was to build support by papering over the problems, the effect has been the opposite. I'm still aware of the problems, but now I also don't trust the advocates to be honest when talking about the problems. At some point I need to sit down and write up something more detailed about what the timeline has looked like, because I really feel like the conversation around passkeys and the way companies have moved forward with them is a really good example of how to just completely kill consumer trust in a standard that could have theoretically been good.
I was really excited about WebAuthN, but even as somebody having read the specification several times and having done a lot of experimentation, it's now more or less a mystery to me when I can add which type of passkey to a given website.
Sometimes I get 1Password jumping in; as of lately, Chrome sometimes realizes that I have a native passkey stored in iCloud(!); until recently, there was also Chrome's local/non-synchronized passkeys on macOS; very often, nothing happens and I realize I'm just on the wrong browser for any of it to work (e.g. Firefox on macOS).
I can't realistically recommend this to non-technical friends and family at this point.
I appreciate what you're trying to do and I'm happy for more providers to build implementations, but you can't individually solve the ecosystem problem because you're only one provider. You can't force Apple, 1Password, Google, and Microsoft to all allow import and export from your app. You can't force Amazon not to do attestation or to accept multiple keys, even if you do everything right you don't have the power to force them to go along with you.
This is a problem that has to be solved by the FIDO Alliance; individual providers can't solve it for them. The Alliance itself has to take some responsibility for the direction of the spec they're pushing and for the direction the industry is going. Ecosystem portability is not going to be solved until interoperability is as a mandated condition for certification.
https://connect.mozilla.org/t5/ideas/support-webauthn-passke...
I’m using it with Google, GitHub, Facebook, Gandi, Fastmail, and Stripe. On some of these websites, the passkey is still seen as security key for 2FA instead of a “real” passkey not requiring a password at all.
Apple and Google are putting a lot of effort in making this work well and it shows.
All the implementations I've seen are walled gardens. We really need some self hosted option that is fully cross platform.
Besides the walled garden I definitely don't trust a big tech player with the keys to my entire online life. Besides tracking and telemetry concerns they can block me for any perceived "terms of service violation" usually without much recourse. Or even because I logged in from an unexpected location as recently happened to my Instagram.
Not so much a problem when I hardly have any data in Google. Huge problem when it's the key to everything else.
> We really need some self hosted option that is fully cross platform.
It needs to be supported by the big players too. A self-hosted option isn't enough.
A self-hosted, cross-platform and Open Source provider that's usable with existing services is a requirement for people who are comfortable with technology and who are familiar with the ecosystem to come on board. People like me need that. But if I'm going to advocate that ordinary people use passkeys, then it's not good enough that there would theoretically exist a provider that wouldn't lock them down.
As long as the default option that their OS is telling them to use is locked down and can't import or export, then the only advice I'm going to give them is "don't use passkeys." I'm not going to deal with a situation where they move phones and I have to tell them "oh, you would have been able to sync your passkeys across ecosystems easily, but you chose the wrong ecosystem to go with, so now you can't."
Inconsistent implementations and inconsistent providers will kill passkeys as a general tool.
But the way WebauthN works, it should be possible for any platform to offer this functionality. I believe 1password already offers cross-platform. But it's not self-hosted which is what I need.
1. The ability to use the same passkeys on a Windows/iOS/Android device. 1Password supports this, Apple is moving in this direction with its Chrome extension. Note that this isn't universally supported, but it's getting better over time.
2. The ability to move ecosystems entirely -- ie, the ability to export passkeys from iCloud onto a Windows computer, or to export passkeys out of 1Password into Bitwarden. No major platform supports this, not even 1Password (although they have at least said they're lobbying for it). As far as I know, there is no timeline for supporting this, and FIDO's current position is that they don't want to require it.
The second problem can't be solved by an individual provider, Open Source or not, because there's nothing in the spec requiring other providers to support export/import and no standard about how that export/import should happen. It has to be something that's tackled by the Alliance, and it can't be an optional part of the spec.
If users have to do research about which passkey provider is safe to use in order to avoid vendor lock-in, then I can't recommend passkeys to ordinary people.
----
This is a common confusion, and it's not helped by the fact that passkey advocates often conflate the two ideas; so people come into passkeys and think, "of course they're portable, everyone is telling me they're portable, everyone is telling me 1Password solved portability." But they're not portable; advocates are just using the most narrow definition of the word and are treating limited cross-device support and in-ecosystem backup as if those are the only things that matter. I've seen advocates argue that the problem of ecosystem independence is solved by Yubikeys even though Yubikeys are even less portable than roaming keys and more locked down. Not only can they not be exported to different non-Yubikey ecosystems, they can't even be backed up within the same ecosystem.
Bitwarden could theoretically get passkeys to the point where I would be OK using them because I'd only ever use Bitwarden's implementation and would self-host and the Open Source nature would guarantee that other people could read the data if I needed to move somewhere else. But Bitwarden can't get passkeys to the point where I'll recommend anyone else use them, because there is no way currently to use any other provider without suffering provider lock-in[0].
[0]: And no, before someone else comments otherwise, manually duplicating all of the keys across devices is not a reasonable or accessible strategy for avoiding lock-in.
Why does 1password need to 'lobby' for an export function though? They could just build one in their software?
But why can't bitwarden be its own provider? I don't understand the constraint there. I thought passkeys were fully open and anyone can be a provider?
There's been a bit of conversation about this online. During the most recent AMA, 1Password's passkey team shared this: https://old.reddit.com/r/1Password/comments/16to6x7/hey_redd...
> we never, under any circumstance, want to allow them to be persisted unencrypted. We don't want vendor lock in any more than you do, but getting everyone to agree on a common spec takes a while. We're trying the best we can to accelerate the process but please understand that defining secure specifications take time.
1Password's position is that it only wants to support export as part of shared standard, my understanding is that they aren't interested in exposing passkeys in a form where it they are unencrypted and the user can inspect them by hand.
1Password is pretty much the only voice I've heard talk about tangible plans for export (part of the reason I use the word "lobbying" to describe them is that they seem to be the member of the FIDO Alliance that I can find publicly advocating for a standard), but I suspect their position reflects the position of other FIDO Alliance members. Absent some evidence otherwise or some FIDO member giving some kind of information to the contrary, I'm assuming that we are not going to get export at all from any of the major providers until every provider agrees on a single standard, and short of individual providers like 1Password lobbying for that to be prioritized, I've seen no information about an official timeline or even any information about where in that process the FIDO Alliance is or whether other providers are interested in working towards that standard.
> But why can't bitwarden be its own provider? I don't understand the constraint there.
Bitwarden can be its own provider. If attestation doesn't go wrong (which is still a risk since lack of attestation for roaming keys is not standardized, we're relying on Apple's goodwill to block attestation on iOS), then Bitwarden will be usable with every service. However, my point is that having only one Open Source provider is not enough to make passkeys worth recommending to ordinary users.
Assuming everything goes well with Bitwarden their implementation might be enough for technical users like me who are familiar with the ecosystem and know how to avoid the many caveats, but ordinary users are going to be locked into proprietary platforms and ecosystems until the export/import situation is sorted for everyone. I can't recommend passkeys as a standard if there's only 1 provider that allows export/import and nobody else is required to work with them.
I don't want to have a conversation with my parents where they find out they can't move between ecosystems because they accidentally used their phone's built-in passkey provider. It's easier and safer to just tell them not to use passkeys.
----
As a side note it's worth mentioning that -- while I assume it will be possible -- I haven't actually seen any confirmation from Bitwarden that they are going to support export either. With an Open Source program it will be possible for someone to add support, but I can't actually say with complete certainty that you won't need to fork Bitwarden and program support yourself if you want to export passkeys. I can't with complete certainty say that someone using Bitwarden's official service instead of self-hosting will be able to export passkeys. I assume they will be able to, I assume there's a branch somewhere on a Github repo I could look at that would show that Bitwarden will allow some form of user-inspectable export.
But I haven't actually found that branch and I can't find any information about what exports will look like from Bitwarden or what format they're considering or if it's just going to be rolled into the existing data vault. If that information is online, it doesn't seem to be in an easily searchable place.
I assume export will be supported in Bitwarden and it'll just be another part of the vault. But it would be nice to get some info about it.
I'm also not entirely comfortable with trusting Apple with this, considering the track record of some big tech with arbitrary blocking accounts, but assuming they block my account, then I would lose the cloud services (used for and syncing and backing up my passkeys), but I should still be able to use my passkeys locally on my Mac and iPhone. For that reason, I'm not sure what is the problem you're describing. It's not really different from 1Password arbitrarily terminating my account, or going out of business.
They're not putting in enough effort. Both platforms still have serious caveats that mean that passkeys are not ready for ordinary users and both platforms are still willing to push this technology on ordinary users before those caveats are solved. That makes me trust them less because if they tell me the technology is ready, I don't know if they're actually using me as a guinea pig or not.
The big caveat (but by no means the only one) is still that passkeys can not be imported and exported across ecosystems (and no, 1Password does not solve this problem, 1Password keys also can not be imported and exported across ecosystems).
And what we're seeing above from Amazon is that even if Apple and Google step up and allow export the ecosystem is still going to be fragmented and overcomplicated as long as the FIDO Alliance refuses to take responsibility for pushing companies to make good decisions about their implementations. The Alliance's deliberate hands-off approach to these problems is why the ecosystem is a fragmented disaster. I don't want to rely on the good will of Google, that's not good enough. These fixes have to be part of the standard itself.
> On some of these websites, the passkey is still seen as security key for 2FA instead of a “real” passkey not requiring a password at all.
This is exactly what I'm talking about, passkeys are designed to be an alternative to passwords, it is a weakness of the spec that they are being used by services as a 2FA token. That's not a positive place for the ecosystem to be, it's mixed messaging about what passkeys are supposed to be.
It makes passkeys less accessible to ordinary people if companies are not even aligned on what passkeys definitionally are supposed to be.
Edit: But don't we have the same problem with TOPT? I don't there is a standard letting us export/import TOPT keys from one system to another (like Authy, Google Authentication, Microsoft Authenticator, 1Password, Apple Keychain, etc.).
We do, and it is a problem. Google Authenticator is a good example, lacking both automatic export (at least it did last time I checked) and (until recently) lacking even backup within Google's own ecosystem. People got burned by Google Authenticator, and I think that is a contributing factor to why real 2FA didn't take off for the general public. 2FA usage is low and is mostly relegated to the tech community, ie people who are able to easily avoid the above issues.
Note that unlike passkeys, 2FA is also not intended to be a replacement for passwords. The use cases are a lot simpler and there are fewer things to be concerned about (for example, unlike with passkeys there generally isn't a need for services to support having multiple 2FA codes linked to the same account). A big part of why I'm comfortable with 2FA is that I don't have to onboard normal users, and the standard itself is so simple that I feel like I could implement it myself if I ever needed to, and unlike with passkeys there's virtually nothing any service could do to stop me.
But putting that all aside, if the idea behind passkeys is to be a replacement for passwords, they're going to need to do a lot better than TOTP did. I use 2FA, but I also notice that it is a frequent usability complaint from non-technical users and honestly from technical users too -- there was pushback when PyPi started mandating it for certain accounts. Passkeys have to be way better than 2FA if they have any hope of seeing wide adoption.
Also note that the export situation with passkeys is a lot worse than the export situation for TOTP ever was. Export for a 2FA app is usually unencrypted, you're basically just exporting a number. So while the lack of requirement to allow export was definitely a problem, the need for a standardized format (as nice as it would have been) was much lower because the format was kind of self-evident. With passkeys that's not the case; 1Password is currently holding off on export because they don't want to allow plain-text export of the keys and they want FIDO's input into how to do it. There wasn't ever a point with TOTP where implementers were saying "we can't export keys until we get instructions how to".
It's a good thing that these are not possible. I want private keys to be non-exportable. This is why HSMs and Yubikeys are so secure, because there is no API to access the private key itself. It prevents hackers from leveraging other exploits to extract private keys.
The only "transfer" process I want is one where I can use the passkey on one hardware device to authorize in real-time the login on a new device, so that I can then set up a separate passkey on that device. This is fundamentally an application concern and not part of the WebAuthn standard, because there needs to be something to push to the device with the pre-existing passkey to ask for authorization.
Cool, I guess, but they are never going to be a replacement for passwords as long as that's the case. Ordinary non-techie users are never going to be OK with that.
We couldn't get ordinary users to use real 2FA tokens. You think security people are going to convince them to build a backup system across multiple devices where they duplicate their keys? It's not going to happen.
> The only "transfer" process I want is one where I can use the passkey on one hardware device to authorize in real-time the login on a new device, so that I can then set up a separate passkey on that device. This is fundamentally an application concern and not part of the WebAuthn standard
This is absolutely something that concerns the WebAuthn standard, because a nontrivial number of providers don't support this.
I'm tired of the passkey advocates saying "backup works, you just have to authorize new devices" at the same time they're saying, "it's not our responsibility to ensure that it's possible to authorize new devices." Okay, it's not your responsibility, but then don't pretend that backup works even under the narrow criteria of cloning keys on multiple devices, because even that doesn't actually work.
Amazon above is spitting out an error code that claims it will only support adding one passkey per-provider. If so, that's the FIDO Alliance's problem to solve if the FIDO Alliance is interested in anyone actually using their spec, because my takeaway from Amazon's messaging is that cross-device registration isn't guaranteed to work.
Chrome on macOS supports passkeys in icloud keychain as of M118. Hiding passkeys because users “struggle” with QR codes is, frankly, stupid.