FIDO Alliance publishes new spec to let users move passkeys across providers
fidoalliance.org
fidoalliance.org
There should be a different standardized term used for hardware bound keys. So users wont get confused.
In particular, they distinguish between "copyable" and "hardware-bound" passkeys. They're both passkeys, and can be used wherever passkeys are supported, but only the "hardware-bound" passkeys support attestation.
The (probably?) most widespread implementation of them (iOS + macOS et. al) isn't; they're synced between devices.
They can be stored in them, but also in software; even when stored in hardware, they can be marked as extractable to some trusted party (a companion device with the same root of trust, a trusted cloud sync service, a supply chain attacker etc.)
If you are worried about state level activity, have it stored in a single place that can be compelled by law to disclose it and that is off the table for you.
Which, sure, you can argue that there are still hardware tokens for people. But that is itself a signal, no?
Make a passkey on your Mac, it appears on your iPhone.
Make a passkey on your Android, it appears on your other Androids.
Anyone who can bind a new iPhone or Android to your Apple/Google account wins your passkeys. I think the only passkeys properly tied to hardware are dedicated FIDO devices.
Yubikeys are tamper-proof and cannot be copied. Everything else is just a place to store a statement that your cloud vendor of choice blesses this gadget to authenticate your account.
The reality is that the biggest pushers of Passkeys are the providers with the least amount of infrastructure stability. If you want people to get to use Passkeys, providing an exit tool from Google and Apple is a must, because both providers are godawful at not accidentally mushing up your data. That's not so important if all you're using their infrastructure for is a periodic backup/use it to transfer photos to your PC, but it's a problem for anything that has to be stored long-term.
And even when they are, nothing says that secure enclaves can’t have importable or exportable keys. Many schemes do both on a regular basis.
That might be the company going bankrupt, a physical or digital disaster, geopolitical firewalls, or simply a Kafka-esque bureaucracy where your entire account has been deleted without appeal because the company decided it was easier than figuring out the truth behind some moderation issue.
Sure, it sucks that anything is interceptable. But this is still an improvement over the status quo.
> These big tech companies will do anything possible to prevent users from ever actually being able to access their own passkeys.
> Export and import should have been extremely simple. Instead, they took years to come up with some convoluted system where the only possibility is to transfer from one vendor lock-in to another vendor lock-in.
> With passkeys, the big tech companies are executing a coup d'état of authentication, just like they did for HTML itself.
> In the end, they control every protocol, become the gatekeepers for the web.
I feel like I either misunderstand pass keys or live in some twilight zone where they're ok even though I cannot wrote them down or memorize them, I can only have invisible magic stuck on my phone.
If I show up naked, I can login to the system via password but I am conpletely useless with a pass key. And for somebody like myself who uses multiple devices daily (two phones, two tablets, several laptops and desktops), it seems a nightmare to set them all up or maintain:-(
It feels a system designed for those who live by their phone and trust some specific service provider with their life. I'm not in either of those categories :-(. I still don't understand what the "Keepass, "little black notebook", and "good memory" equivalents are.
It’s probably different for everyone but in case I have strictly separate devices- so a laptop where I have my work accounts and a desktop for games and some personal stuff.
I don’t really use anything on a regular basis that needs accounts on my personal devices, but that’s probably very weird nowadays…
It is a solution designed to lock people in the Apple/Google walled gardens, and I don't see why everybody is pushing for it.
They're literally a cryptostring stored in your password manager just like your other passwords.
So I can copy paste them somewhere or move them around without "Credential Exchange Protocol (CXP) and Credential Exchange Format (CXF)"?
"You can't take your passkeys from Apple Passwords"
s/iCloud/1Password?
"There's not a way to import/export passkeys"
s/iCloud/Google?
So "you can copy paste them using those formats, if you can get them into those formats in the first place".
It’s clearly not (just) a security but a lock-in feature.
And Android 14 seems to allow changing the passkey provider in the android system as well. With that, the only thing left would be a KeepassXC-compatible app that can serve as provider on android, using the same database as the desktop.
With that setup, I'd be willing to use passkeys exclusively (my phone is still Android 13 and I don't know about app support). I already can't login anywhere (important) without access to my password manager.
Last time I checked, the Bitwarden Vault export included the whole FIDO credential including the private key.
As a keepass database is used by various open source clients from different vendors, it just takes a little longer to get all this done. But I'm sure we'll get there eventually.
It's worth noting this is also supported in iOS and macOS.
Settings > General > AutoFill & Passwords
There seems to be a lot of misunderstanding of passkeys indeed. They're in no way different than that random password stored in your password manager and can be (with this standard you're commenting on) moved around wherever you want them.
All passkey sites also support fallbacks to just password or other auth mode.
Except in all the ways that matter: they are not accessible to users, they are tied to third-party vendors.
Is this a guaranteed thing? Are we saying any account I create cannot be Created with just a pass key; and that no site or service is able to discontinue the password option?
I actually built a small web application that’s entirely passwordless, and it works really smoothly. I don’t get the antipathy towards Passkeys.
I feel I can take a password and print it on paper, memorize it, save it on a USB stick, tell it to my wife. I feel in control with passwords. Nobody owns them but me.
Passkeys feel like a wild wild WILD west of providers and islands and standards. It feels like if I sign up to a website on my iPhone creating a pass key, it is a nontrivial amount of work and even less trivial amount of knowledge to transfer it to my android tablet or windows pc. Or maybe that's not even a thing and really I need to resign up on those devices? Or i need to authenticate a second device with my first one? So if I sign up to website 1 with my phone and website 2 with my tablet and website 3 with my laptop,if I want to access all of those from all my devices, I now have a fun weekend of syncing or something?
And I have no idea how to help my mother inlaw with it unless it's some "create Icloud and trust apple and pray " system.
More than anything, you prove my and disprove gp's point that passwords are not necessarily always going to be an option for all sites and services. In fact it feels everybody is yelling in my face that passwords are gone and this half baked complex system will be the only thing.
But reality is exactly the opposite: You don't own your passwords. You hand it out freely to sites you create an account with, and rely on those sites to store the passwords securely. Many don't; either way, you don't know. Regularly, sites get breached and millions of passwords—including yours—are published. That is the least form of control over credentials I can imagine, lest yourself publishing it online.
Passkeys alleviate this by creating an account/site scoped key pair, and only handing out the public key to the site. Breaching a Passkey-only service is futile, because those public keys don't work anywhere else by design. The only one in possession of the private keys is you; compared to passwords, that's infinitely more control.
> Passkeys feel like a wild wild WILD west of providers and islands and standards.
I don't quite understand why you feel that way; there's a single, open, freely accessible specification, implemented by more and more vendors.
> It feels like if I sign up to a website on my iPhone creating a pass key, it is a nontrivial amount of work and even less trivial amount of knowledge to transfer it to my android tablet or windows pc. Or maybe that's not even a thing and really I need to resign up on those devices? Or i need to authenticate a second device with my first one? So if I sign up to website 1 with my phone and website 2 with my tablet and website 3 with my laptop,if I want to access all of those from all my devices, I now have a fun weekend of syncing or something?
Ideally, you would sign into the service with separate Passkeys per device. A mechanism many sites implement is that you can sign in on a new device by letting the browser show a QR code that you can scan with a previously authenticated device to complete the authentication process. It's really straightforward. And if you don't want that for some reason, you can usually choose to send an OTP to your email or phone and use that for the initial signin, then register a new Passkey for the new device.
I totally see how the burden of making it user-friendly is on the particular site here, and the instruction quality varies between vendors—but that isn't on the technology itself.
> And I have no idea how to help my mother inlaw with it unless it's some "create Icloud and trust apple and pray " system.
If you don't trust Apple, install a password manager like 1Password on her devices and let its browser extension handle the complexity. Source: My mother.
> More than anything, you prove my and disprove gp's point that passwords are not necessarily always going to be an option for all sites and services. In fact it feels everybody is yelling in my face that passwords are gone and this half baked complex system will be the only thing.
I'm sure you're an intelligent individual and would really encourage just reading up on Passkeys and the problem's they're actually solving. Passwords should be gone for a variety of reasons, and Passkeys are superior. While I do see how communication around Passkeys was sub-par, I don't think there can be doubt in how asymmetric cryptography is better than passwords in terms of security and usability, if done properly.
They work perfectly well for 95-99% of people, but oh boy are you screwed if you are in the remaining 1-5%…
Unlike for all these other “forms of identification”, there’s a chance passkeys will bridge the remaining gap, but we’re not there yet, hence many people are cautious.
What's more, passwords work well for a much smaller percentage that has learned to use password managers. Everyone else is subject to regular breaches, and suffering. This is a problem Passkeys get rid of entirely. There is no good argument against using Passkeys over passwords. Not one.
I was referring to how 99% of people have (or can easily get) an SSN, license etc., but for 1% it’s absolutely impossible for various reasons, so any flow requiring one for non social security or tax declaration purposes is an unnecessary obstruction to them when other alternatives exist.
Don’t ever believe that passkeys will always stay strictly optional. As soon as something works for 99% of potential customers, the 1% can be deprecated for efficiency/security/… purposes.
And I’m even not anti-passkey or anything, I personally like them and will take them over SMS OTPs any day. But they’re just not done yet, and I really hope they get done in a way that works for everyone before they start becoming mandatory in some places.
What reasons are there for not using Passkeys? So far, the only things in the threads here were vague fears of vendor lock-in by people who apparently overlooked the fact that Passkeys are supported by a lot of password managers other than just iCloud Keychain and Google, including open source software.
What is this 1% that we should sacrifice a clear solution to password breaches for?
I just wish their governance was a bit more aligned with users rather than just big tech. This would be something where Mozilla could really shine, for example, but I haven’t really seen them in the relevant forums, and they were quite late on WebAuthN as a whole.
Some focus on avoiding lock-in and (somewhat orthogonal to that) enabling non-cloud credential duplication would be great, to name a few remaining issues.
SSH keys started out as standardized, interoperable plaintext files (with an option to use GPG smartcards or other hardware credentials or custom SSH agents if you need them).
Passkeys are the opposite. And defaults matter.
> Passkeys are essentially site-specific cryptographic keypairs, which are fine, combined with big tech company paternalism, which is intolerable.
The remaining issue is moving the credentials between providers, which is an annoying limitation. But you can always add a different passkey to the site using the provider you want, so although annoying it is not the end of the world…
The original limitation is similar to the usability of actual physical security keys, which (depending on the setup mode) are deliberately designed such that the private key material is not recoverable. Software based keys don’t HAVE to share the same limitation, but it seems more like a missing feature than attributing malice to the creators of the spec.
Why should we even need a third-party provider? Imagine needing a third-party "provider" for your own ssh keys.
When I use passkeys on a single device, the "provider" is the OS, same as with my SSH keys.
Yes. For example, when upgrading or reinstalling a system
> If you need or wanted to (you don't) you'd need some way to sync them across multiple devices securely.
`scp -r`
> the "provider" is the OS, same as with my SSH keys.
And you have full access to ~/.ssh and you can move copy update rename delete them however you like. Without a "Credential Exchange Protocol (CXP) and Credential Exchange Format (CXF)" to move between blackboxes of third-party providers
I think this comes down to me never having wanted to do a copy or move (I create and maintain new keys when I create new devices) which is exactly the same experience i get with a passkey (and is, generally a more secure experience since my keys cannot be exfiltrated since copying them is implicitly verboten).
Assuming you mean client devices, yes, depending on my personal relationship/control of the device. (For servers, the answer is "very yes".)
For example, my personal laptop and desktop may have the same private key, and I will backup/restore that same key onto either of them if they are reinstalled or replaced with new hardware.
However my work laptop gets its own, so that I can more-easily limit what it can access or cancel it in the future.
Yes.
> you'd need some way to sync them across multiple devices securely.
I take out my physical keychain and plug in my yubikey. Then, after typing in the password to my yubikey, I can use ssh and pgp until I unplug my yubikey. It is a hell of a lot more secure than storing your ssh keys on disk regardless of whether or not you use a unique key per device. I could lock someone in a room with my computer, my yubikey, and my password, and they still wouldn't be able to copy my ssh key.
How do I ensure I can access my accounts if my phone-containing-passkeys is lost/stolen/dies without backups?
Whether that's having multiple separate keys/devices registered with your accounts or a single key stored in a password manager, you need to have a fallback plan.
My example was only to point out that there exist self-hostable passkey providers.
Standards are slow and expensive to create and evolve. They involve endless meetings, discussion and design. However, the outcome is freedom.
The idea that this should have been “extremely simple” is just standard hubris.
> However, the outcome is freedom.
This is an exceptionally naive take.
> The idea that this should have been “extremely simple” is just standard hubris.
Why? Export-import of passwords is extremely simple and can be done with copy-paste or CSV. The only thing preventing this with passkeys is the paternalistic idea that users of passkeys should not be allowed to access them directly.
This is, of course, also the thing that makes passkeys uniquely unphishable.
The sentence is true, as far as it goes... But it's uniquely excessive, rather than the unique minimum sufficient for the task.
The hint of why this may be just slightly complicated is in that final phrase.
The hint is that they are putting the cart in front of the horse, have decided on an outcome, and now are busy working towards that outcome.
ssh isn't less secure, and yet you can just copy-paste the required files on your own, instead of relying on convoluted protocols for moving data between black boxes.
It reminds of of their "Data Transfer Initiative" which "let's people move their data around easier" but underneath it's just "well, some of data between Google Apple and some other third party services only": https://dtinit.org
Designing a system that is secure, scalable, and works for billions of people worldwide in a highly adversarial environment is freaking hard.
You're lumping together the data and access that SSH keys protect (which might be actually nothing) with the key mechanism themselves. The private key itself can be armored or stored in a Yubikey itself, or you can even use more exotic ways of protecting it.
The public keys can be easily automated while the private keys stay safe somewhere. Systems like SSH Universal Key Manager or Userify are out there (both on-prem, and Userify also has saas) to make maintaining the public keys across huge swathes of servers relatively simple (or sometimes extremely simple).
And not just authentication, but authorization, too (usually through something like sudo or doas). Or you can just roll your own with Ansible or LDAP (not nearly as flexible when dealing with two axis of variations - users and servers, but still doable). SSH keys being easy to manage is extremely important, because when things are hard to manage, people open security holes, either through ignorance or to save time.
So, like all keys, yes, SSH keys can be a massive security liability if not properly secured, but they're not so (intrinsically), or even by default.
Similarly, I wouldn’t copy a private key for ssh to a new laptop. I generate a new one and copy the public key instead. It makes it easier to revoke access to the old computer.
I do think this new spec will sometimes be useful for populating a new password manager, though.
I've never seen a single sight suggest this either. Many have set up passkeys, but not one has prompted me to create a second. I have downloaded a lot of backup keys though.
Sorry to be on blast here but every time passkeys come up the "use multiple keys" gets said & it's a joke. There needs to be a flow where I can create a passkey & have it replicate to a bunch of devices automatically; the current proposal that users need to gather all their security tokens & add each one is an absolute promise this technology is going to flop.
Choose a passkey provider that supports this then. I use bitwarden. Other people use iOS keychain. Both work great.
Apple and Google both replicate between devices, so there is some replication, within ecosystems. I only need to create a passkey twice per account so I can use both. It’s not a big deal, though replicating between them would be better.
And so I am clearly not locked in. (Not because of passkeys, anyway.) If people think they’re locked in then it’s a “can’t be bothered” sort of lock-in.
Clearly not fantastical since I’m doing it.
Imagine having to use a specific password for each service/device combination. Instead we don’t tie passwords to devices, but to users, to avoid this complexity.
Everything but employer stuff was cheap on Facebook marketplace. I am a bit on the tail end of my friends and coworkers but not by much. It's always been supremely convenient to be able to choose the form and location of my computing device. The cheap devices are largely disposable - I have several layers of backups. It is this perspective that makes passkeys seem strange, a Cartesian joint of many-to-many between my devices and providers that quickly gets... insane.
(This is in context of Passkeys. If your question is ssh, substantially less:)
But that is the entire premise of Passkeys—they remove the complexity, because having individual passwords per device is clearly superior to user-bound passwords, if you don’t need to worry about it and it just works. Hence why, to stay with SSH, you shouldn’t use SSH keypairs, but certificates signed by a CA.
(The added bonus security feature being you could revoke your daily driver if you lose it, while retaining access to your backup. But again there's no actual support for this kind of thing)
Can someone explain how this actually works? Are the two backends required to send messages to each other to facilitate a transfer, or is it a simple encrypted export and import? Will it only facilitate transfers to trusted destinations?
Are passkeys replacing passwords, 2FA, or both?
What if I created a passkey on some device, lost that device, and my passkeys aren't cloud-backed-up? Would I be able to recover my account, or it's doomed? Or does it depend on how a given website implemented it?
It’s just your login credential.
If you lose either a password or a passkey, you do the same thing: set a new one via email recovery.
You kind of have to go out of your way to not have your keys backed up. By default, the easiest route is using your android or iphone and both of them back the keys up using icloud Keychain or google password manager. 1Password, bitwarden, all support syncing. Chrome will allow saving it to icloud or your google account. Keepass can be manually synced. Windows is adding sync in the next update for windows hello. List goes on.
The other thing is that multiple keys can be created. Easiest way to see this in action is google's account security settings. Log in (if you have an account), hit create passkey, see your options and play around with them. You'll also see you can add a hardware security key too, which isn't nothing new but if you have one that's another key that doesn't rely on a mobile device!
If all else fails, the usual account recovery process applies. Much like it would if you forgot your password.
And if my google account gets banned, I lose access to a trillion things instead of just one.
I was hoping passkeys would work on 1password,but chrome/brave don't support that yet.
It seems like a passkey is just a password though
They're as secure as having your password + 2FA in a password manager.
[0] https://github.com/keepassxreboot/keepassxc/issues/9339
[1] https://keepassxc.org/blog/2023-06-20-cve-202335866/
edit: This actually might be a better thread to hear some of the debate between an Okta dev and the KeepassXC team:
EDIT: Private key is not transmitted off of your device when authenticating, but it can be transmitted off of your device by your password manager.
"The difference between passkeys and passwords is that passkeys are cryptographic key pairs. The key pair is specific to a website. One half is shared with the website, and the other half is private and stored on your device or in your password manager." [0]
"Passkeys are securely backed up and synced between your Android devices" [0]
"Passkeys are stored in your Google Account..." [0]
"Your iCloud Keychain stores and syncs them [passkeys] between iOS, iPadOS, and macOS devices." [0]
Thank you. I should have been more specific. Non-transerral during auth is important because it virtually eliminates fishing, and that also explains why the Powers That Be are touchy about exporting. Exfiltration enables scenarios where a nefarious party tricks a user into transferring their cryptographic keys.
[1]: https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...
That depends on the site. For Google, sure you can add multiple passkeys. But many other sites will just do minimum effort and only allow you to register a single passkey.
They are advertised as a replacement for passwords, but the truth is that they are orthogonal to both passwords and 2FA. They are a completely different kind of authentication.
Both passwords and passkeys work by proving that you know a secret. The difference is that with a password, the way you prove that you know the secret is by revealing it, which leaves you open to phishing. The other problem with passwords is that the secret is generally one that you are expected to type and remember, which limits how long and random it can be.
With passkeys, the secret is a public key (EDIT: in the sense of public-key encryption. The secret is actually the secret part of a public-private keypair), that is, a long string of random bits that a normal human could not remember even if they wanted to, and the way you prove that you know it is using that key to produce a digital signature for a random challenge. You never reveal your key during normal operation, and that makes it more resistant against phishing.
> What if I created a passkey on some device, lost that device, and my passkeys aren't cloud-backed-up? Would I be able to recover my account, or it's doomed? Or does it depend on how a given website implemented it?
It depends on how a web site implements it, but keep in mind that everything that makes it easier to recover from a lost key also makes your account more vulnerable to attack. So having backups of your passkey keys is a really good idea. But those backups don't have to be in the cloud. You could keep local copies on your own devices, or even print the key on a sheet of paper and keep that in a safe.
It depends on the type of attack being mounted, but a typical phishing attack is mounted as a MITM attack. With passkeys, a MITM cannot get the client to even ask the user to approve the transaction because the attacker cannot authenticate as the relying party.
You can attack passkeys by, say, compromising the user's machine, but that's not phishing.
WebAuthn credentials are bound to the issuing domain, so the user agent will not supply a passkey to a domain other than the one it should go to.
Obviously this isn't bad advice, but it is the reason I won't be diving into passkeys any time soon. Firefox Sync (the original version) had this philosophy: it's perfectly secure but if you lose your key, you've lost your bookmarks, history, and anything else that gets synced. For non-power users this is a catastrophic failure mode. For power users this still happens and it sucks. I was at Mozilla during this time and the failure modes of Sync were impressively common, even among employees.
Nobody expects to lose their backup. If you were a victim of hurricane Helene, it's entirely likely your safe is gone and all of your devices are destroyed. If that also means you've permanently lost access to your files or email or whatever, that's really really bad. And completely within the realm of possibility!
Obviously you can't fix this with cryptography alone. But it shows that passkeys can't be implemented as a full solution.
Well, OK, but what is the alternative?
(Actually, you don't need to manually keep backups. You can have automatic backups, but those come with their own set of risks.)
Banks aren't perfect but mine already has all my money and the deed to my house. I trust the safety of my bank more than I trust Google not to lock me out or all my hardware to be destroyed.
Based on my (limited) understanding from reading the page: 1. Server generates challenge, sends a challenge 2. User device signs the challenge by encrypting with its private key, returns the signature. 3. Server verifies the signature by decrypting with the public key.
As you mentioned, the private key (the only thing that can generate a valid signature) isn't leaked.
Yeah, I meant "public key" in the sense of "public-key cryptography". I've edited the comment to make this clearer. Thanks for pointing that out.
> Based on my (limited) understanding from reading the page: 1. Server generates challenge, sends a challenge 2. User device signs the challenge by encrypting with its private key, returns the signature. 3. Server verifies the signature by decrypting with the public key.
That is almost exactly right, but since we're being precise here, I would just pick on this one very minor nit:
> User device signs the challenge by encrypting with its private key
> Server verifies the signature by decrypting with the public key
"Signing/verification" and "encrypting/decrypting" are two completely different things. In RSA these are conflated, but it's important not to confuse them. With elliptic curves, these have nothing to do with each other. It's just a peculiarity of RSA that makes it encrypt/decrypt to do digital signatures.
The minimum bar is replacing passwords with something more secure for the user.
If the site wants more specific factors or characteristics of authentication (such as a non-cloneable possession factor) then only some authenticators provide that today themselves. For someone using a synced software provider, they will need to do an additional step to meet this sort of requirement.
Factors aren't nearly as solid as they are made out to be - my SMS OTP is synched to all my devices, my TOTP keys come from a software implementation right alongside my password - which isn't a true knowledge factor because it was auto-generated for me. Password managers and other software have long put us on the path of sites leveraging externalized authentication processes and policies, similar to how they might do this explicitly by accepting federation.
> What if I created a passkey on some device, lost that device, and my passkeys aren't cloud-backed-up? Would I be able to recover my account, or it's doomed? Or does it depend on how a given website implemented it?
The syncing is meant to make it harder to lose the passkey. Sites still ultimately have to have a recovery process when someone does lose access.
Do they? Is that legally mandated somewhere, or can they just say "You're stuffed, make a new account if you want"?
It’s just your login credential.
If you lose either a password or a passkey, you do the same thing: reset and set a new one via email recovery.
It can also be used as an second factor for traditional username/password auth (with or without user verification).
Losing a passkey is no different to losing any other credential: you need another method to authenticate or recover your account.
It turned out that no (mainstream) passkey provider allows backups however, making them infinitely worse than just using passwords.
Maybe this will help, but fuck me, it’s all complicated, especially for a damn foundational security mechanism!
It could be so simple, just look at SSH keys, which I think largely use the same principle.
Figure out which doors you need to unlock and make sure you have at least two independent ways to get through each door. Some doors support Yubikey, so that counts as one, for those doors.
Actually backing up keys, as in duplicating them and physically securing them, makes it simple, clear, and understandable to all involved what recovery looks like. TOTP is a great example in a similar space; my nontechnical spouse doesn't need to know "how TOTP works" to know that in case of my incapacitation she only has to read a packet of paper and follow instructions in order to perfectly recover all my accounts with zero chance of some 3rd party provider (e.g. Passkey stores like 1password/Google) having a political/technical glitch that'd get in the way of that.
Passkeys are like passwords with landlords added in. Just like with landlords for services provided, Passkeys seem very convenient for day-to-day but nightmarish in the margins and on the 5+ year scale.
Two different combinations for the same lock serve as backups for each other for practical purposes.
They could even be entirely different methods of access, like a Yubikey or backup codes. What matters is that you have independent ways to get in.
The qualifier “mainstream” is quite silly here. Bitwarden and KeePassXC work great, can be backed up, and meet your needs. Why must “mainstream” providers support power user features?
In-practice, 1Password, iCloud Keychain, etc are backed up because they work across devices and those systems already have recovery mechanisms in place if you lose your devices. They’re synchronized credentials available everywhere.
The only way to make a problem is to “store a passkey locally”. Then you’re out of luck. If you just use Bitwarden or KeePassXC, this is a non-issue.
> It could be so simple, just look at SSH keys, which I think largely use the same principle.
Passkeys are technically complex in implementation because they’re trying to be better than passwords for the lowest common denominator of users. If you spend time looking at how they work and interact with sites, the solution is relatively simple and easily understood. Maybe they’re just unfamiliar to you? I personally have never explained to a layperson how SSH keys work without first explaining PKI, which is a pretty big ask for my mom.
On the other hand I like the security benefit of hardware passkeys. But these are unusable because 1) most sites that support passkeys don’t support registration of more than one passkey, and it’s hard to determine if they do or not, and 2) the security benefit is defeated if sites allow recovery without a registered passkey, which most do, and again it’s hard to figure out if they do or not.
So what’s the point?
I have recovery mechanisms for regaining access if I lose all my keys, but (while I'll admit that the tooling for managing public keys in the general case is lacking) you're not supposed to (need to) copy private keys between devices.
Technically you can generate a GPG key and load that onto multiple Yubikeys, but that's not as secure as letting the Yubikey itself generate the key. Plus if you only use one GPG key and one of the Yubikeys is lost (but not destroyed) then you have to rewrite all the remaining Yubikeys with a new GPG key since you can't selectively revoke them.
Lots of complaints about passkeys and "big tech paternalism" in the comments here, and frankly I don't think ya'll deal with the middle of the bell curve user base that much.
I've got users who, by literally no fault of their own, are being social engineered into reading back their SMS OTP codes to fake tech support. State of the art in industry is basically trying to understand every action that is happening on a device (via mobile phone network providers, location, their actions across multiple other sites, etc. etc. through vendors providing this type of intelligence... by vacuuming up all your data) to understand if fraud is happening by seeing if you can even trust the device that is getting the SMS. Every time we make a step forward in privacy, this gets harder and harder (fingerprinting devices is basically pointless now, so how do I tell if this should be a trusted device or not) so there is a driving force against improving user privacy coming from these vendors.
Passkeys are the first positive step in auth I've seen in a decade that the average user will pickup and use, it helps them login and helps them not try to set a weak password they shared with multiple sites, and they can't read it back to a scammer who is fake tech support.
Would I like passkeys to be more like ssh keys? um, maybe but I don't care about it one bit in practice. I use passkeys for everything I can and I've never once seen friction. The average user does not want to deal with backing up their passkeys or even thinking about them, heck most of them don't. If anyone in the comments doesn't like the implementation of webauthn, suggest changes to the spec and do the work to get it implemented instead of complaining about it in the comments.
Simple: clients meant for consumers SHALL NOT provide any attestation information. Those fields are intended to be used only by managed devices.
People can be free to use a device that has guard rails for them. The issue is when e.g. my bank forces me to prove I am using a malware device, which is pretty much everything from "big tech". Normies will stay on the normal path anyway and will be using one of those devices, so there shouldn't be a need to block the people who are using something weird, because by definition they are not the average user.
High(er) security environments exist, and some extremely anti-user features make tons of sense there - anti-user is kinda the point, you don't want people to do anything they like. But those environments should not be allowed to impact any other environments, it's just going to foster abuse. MDM divides them very cleanly.
There are businesses and their employees trying to influence passkeys to push more towards their business models, because this does shut down a whole avenue of fraud and associated fraud fighting tools that are no longer needed, so there is a boatload of money out there trying to make passkeys worse. Comment on the spec and make your voice heard please.
Both Apple and (I believe) Google threw theirs out when they moved to synchronizing passkeys, and they’re both widely supported by relying parties.
Other than that, I think it’s fair for e-signature etc. services to be able to require a physical, non-synchronizing credential like a Yubikey. With such a service, it’s not just your (as the key owner), but also others’ security on the line when breaches happen.
Rip out resident keys altogether. They aren't needed. You can get 99.9% of the benefits of Passkeys by using non-resident keys - literally the only drawback is that you'd need to enter a username.
Resident keys essentially kill physical tokens. Without resident keys a $10 token can support thousands of websites. With resident keys? A couple dozen, if you're lucky.
Can you elaborate? I'm curious. Is there a storage problem?
Non-resident keys are so much better, because you won't need to worry about this limitation.
So yes, we are living in different worlds. But what we all want is to migrate to more secure authentication methods. And pushing non-residential keys to the wayside just for the convenience of not needing to remember user names feels like a bad trade-off.
I have reread your top post a few times and I think I'm starting to understand your point. To highlight the core part:
> State of the art in industry is basically trying to understand every action that is happening on a device
I wasn't aware that this is happening. And I can understand why fintech companies engage in this invasive practice. However, I never used SMS as a second factor, because I know that it is unsafe. I use hardware tokens, because I care about security. I know that many people do not care about security and it is your job to catch them before they do something stupid. I understand why you like passkeys so much.
But the original point remains: Resident keys are not necessary. Big tech is propagating resident keys. But they could easily use non-resident keys and offer remembering the usernames for the different sites like password managers do it today. It would be an easy win for everyone.
My goals are just protecting my user base from fraud and giving them an easy way to login securely. You would probably be shocked at the volume of support calls we get about logging in. It’s 30-40% of the call volume. Easy for a scammer to slip into that stream as well.
The only thing needed to preserve their utility would be a minimal rewording (e.g. change “preferred” to “possible” or add a “preferred-if-unlimited-storage” for ResidentKeyRequirement), and a requirement of relying parties to add a username field as a fallback.
Or, future tokens start bundling a bit of flash storage and make this a non-issue. Considering how cheap it is, that ought to be possible even for low-cost tokens.
That’s great for you, but they don’t currently work like that for anyone
- using anything other than Chrome or Safari (many sites perform broken user agent based support detection)
- using both iOS and Android (at least not without setting up a third-party password manager, which not everybody knows how to do, or even why)
- not using iCloud (iOS just outright refuses to store local-only credentials, last time I checked at least)
Passkeys are absolutely an improvement for anyone able to use them, but that’s still strictly less users that can use passwords. And even for those that can use them, the availability story is still worse (almost by design, but that’s no consolation for a locked-out user).
> If anyone in the comments doesn't like the implementation of webauthn, suggest changes to the spec and do the work to get it implemented instead of complaining about it in the comments.
I have, with no success. There seems to be a misalignment of priorities and incentives. I even understand where the editors are coming from, but like most industry-sponsored specs, it’s really not the democracy you’re trying to paint it as.
You’re 100% right that the experience isn’t seamless yet for people outside of apple’s ecosystem or google’s but this is just catching hold, and the spec isn’t complete, this original article demonstrates a real improvement that should fix a pain point.
So, I do appreciate the way you’re engaging on each point, but I don’t understand what changes _you_ would like to see.
>Using anything other than chrome or safari These will improve as support improves, I see failures and then have to deal with support calls when the user is on something that isn’t supported well. I don’t check user agent, but it would cut down on my support costs.
>using iOS and Android without a 3rd party password manager
Ok, I understand the problem here, and I think I understand the issue with passkeys not being savable like a ssh key, because the apple and android ecosystem is using its keychain and syncing that keychain with its respective cloud service, you can’t use the same passkey on both systems… but the restriction here saves the users from losing these digital keys or having them stolen, and saves me as someone trying to protect their money from basically having to make a passkey need enough secondary data about your device and other factors. I think you’re missing what I posted about for 2 factor… to support it right now for anything other hardware keys (which are basically only supported in volume by a different central authority, like the IT dept)
I need a huge data vacuum operation on the backend to know who you are, where you are, what device you’re using, what that device has been doing recently, if you’ve swapped your sim, etc etc etc. as a counter, you can just make a passkey on the iOS and the android ecosystem, and now you’re good. Extend this to any other ecosystem you want. Yubico has an author on the spec, they aren’t ignoring the use of hardware keys. I’m sure you would be happy to not participate in that data vacuuming operation, and while it’s dual use (marketing and fraud prevention) they still have a veneer of use for the consumer.
Perfect is the enemy of good in this case. Let’s help all these regular people not get scammed
Absolutely! But on the other hand, let’s not stop at good either if there is a path to something that works for everybody. I do think there is one here!
> I don’t understand what changes _you_ would like to see.
Largely three things:
- Bring back device-local keys with attestation. (Less of a spec issue than an implementation one.) Unexportable hardware keys had value for various contexts like payments, where “delegation” to a third party provider has a specific legal/regulatory meaning and might be a dealbreaker; passkeys kind of made enforcing that impossible (and so they don’t get used by many banks, for example).
- Add an option to “entangle” multiple hardware authenticators securely, such as a pair of Yubikeys sharing a root secret and supporting only non-resident credentials. I could put one in my safe, friend’s house etc. and enroll it into new services without constantly needing access to it. (This one also seems doable without spec chances, but would presumably be much safer with them.)
This one would solve the biggest availability obstacle I’ve seen people mention here and experienced myself to using hardware authenticators, driving people (including myself!) to cloud-syncing software authenticators instead.
- Cement key exportability and an open private key storage format in the standard much more than it currently is. Put it behind a lot of glass (or users will get scammed out of their private keys), but do let me break that glass if I decide to.
entangling multiple hardware authenticators... I'm trying to imagine what this looks like from the implementation side. Are you thinking of something like Shamir's secret sharing being built into the hardware tokens? Because from my side, I send you a challenge and you respond, I don't really care how your system is setup.
Key exportability is basically where I get off the bus. I don't care what kind of glass this is under, people are going to get tricked into doing it and then it will undermine the whole system. I'll have to go back to trying to discover everything I can about the device and if it's been compromised, hell the caller with the key is going to look far more legitimate to my systems than the actual customer.
Passkeys that require embedding on personal devices like cell phones means direct affiliation with your identity, no? Seems like a shadow benefit to industry is perfect ad targeting across the web.
Monopolists will try to erode options and force everything on to their platform but if they didn't succeed with OAuth I don't see them being further ahead with warping the fido standards to be like it.
If someone steals my phone today, I can still access most of my accounts, and can regain access quickly to the others.
Now let’s assume passkeys are ubiquitous and used to log in to every website.
If they can’t be exported, then your entire digital existence is at the mercy of whatever device or technology platform you use to store your passkeys. If you lose access to the platform, you also permanently lose access to every single account you’ve ever signed up for. For me, that would include losing access to my retirement savings, tax records, and the ability to communicate with many of my friends, to give a few examples.
My computer also doesn’t have Bluetooth, which means I can no longer log in to any websites on it even when I do have access to my passkeys.
Shure not everybody does that and some sites don't really support that but thinking about this concept of having "physical key s" to your data makes a lot of sense to me.
Don't know how this change will affect my trust in the concept
So now I need to buy an extra phone from a different manufacturer than the one I already own, or sign up for another paid service? I’m starting to see what their motive might be now.
Is it even a requirement of the passkey standard to allow the user to create more than one passkey for your website?
1. You accept a non-trivial risk to be locked out forever of what you used those keys for 2. You still have a password login to revoke/create keys 3. You invest in enough redundacy to never lose all of your keys
IMHO only 2. is viable and then keys are just a different implementation of a password manager.
Of passkeys, I have quite a bit more, with new ones added at least every few weeks. That makes them much harder to physically or even logically replicate one by one.
How often they change is irrelevant, the point is how you would recover them.
> Of passkeys, I have quite a bit more, with new ones added at least every few weeks. That makes them much harder to physically or even logically replicate one by one.
But what is your plan if you lose them? either you plan to never lose them (3.), you have a way to replace them (2.) or you accept the risk to get locked out (1.)
It’s just your login credential.
If you lose either a password or a passkey, you do the same thing: reset and set a new one via email recovery.
If that’s an option (and it often really is!), why go through all the trouble of implementing passkeys and not just implement “login via email”?
For some services, that’s not secure enough though.
How is it irrelevant if I can only use my recovery authenticator for the services I’ve enrolled it in, yet enrolling multiple physically separated authenticators is a huge pain practically?
It’s like changing the locks on various doors in my house every other week and trying to have a copy of all keys with friends or relatives living out of town.
It’s just your login credential.
If you lose either a password or a passkey, you do the same thing: reset and set a new one via email recovery.
Resetting 2-factor authentication by proving access to only one factor (email) defeats the purpose of requiring 2 factors. If they can be reset via email, they might as well not exist at all. Even if we assume that nobody other than the user has legitimate access to the emails sent to the user (which is often untrue), emails can be trivially intercepted by a third party.
Not to mention that if I’ve lost access to the device where I am signed in to my email account, I won’t be able to access my email account to reset my passkeys anyway, because access to my email account would also require a passkey that I no longer have.
No actually! The biometric auth is more of a “liveness check” than anything else.
The point of passkeys is to replace the primary factor — the password — with a new primary factor that isn’t fundamentally “broken” in the ways passwords are. Password hashes can be stolen from servers, users frequently reuse them across different services, they are frequently very weak, and they are phishable. In contrast passkeys are guaranteed to be strong, unique, and there is nothing worth stealing from servers for attackers (only a public key).
Allowing both “something you are” and “something you have” to be reset simultaneously via proof only of “something you know” (the password to your email account) means that once that reset happens, you’ve gone from two or three factors to one factor.
Allowing passkeys to be reset by email is not compatible with using them as anything other than the primary factor. If you’re using them as both factors, you’d get equivalent security if you implemented sign-in via only magic links. If you’re using them as the second factor along with a password, but you allow them to be reset via email, you actually only have one factor.
Properly managing multiple ubikeys and the like is a huge pain the butt.
> your entire digital existence is at the mercy of whatever device or technology platform you use to store your passkeys.
Passkeys come with enough friction and hassle that I don't actually use them. The ability to move or back them up removes one of the friction points.
I'd expect good vendors to be popping up "You haven't updated your passkey for this site since you migrated to us, you should go to your account settings and do so" on login to a site.
The need for this compromise doesn't even make sense in light of all the past compromises. We pretty much know the RP is an an always online web site instead of variety U2F enables because that was apparently too hard and thrown out with everything else that didn't please always online keyvault makers.. Who is needing to compromise here?
The whole "platform authenticator" thing enabling passkeys came later. Extending the spec that way was easy: a platform authenticator works just like a hardware authenticator, it just uses a different channel for communication.
The spec the providers built upon just wasn't designed for software authenticators that allow moving around credentials. The original spec assumed credentials are stored in a non-extractable manner in HSMs.
Edit: thinking about it, platform authenticators may have been in there pretty early, but under the assumption of also using an HSM and not allowing extraction of credentials. Providers compromised security for usability, removed the HSM and made passkeys synchronizable – the spec had to adapt.
Where's the lockin?
Are there any examples of any widely-used sites that are enforcing attestation?
- Cloudflare had a "captcha" POC called "Cryptographic Attestation of Personhood" where you need to use a FIDO-approved token. It's reusing U2F just for the attestation part only. I don't think it ever go to production as most people don't have a token (but perhaps in the future hardware-locked passkey may serve as one...)
- Okta do have an option to enforce attestation. By default it is off, but in my Okta production I can limit the list to FIDO-approved vendor only, or to even a subset of them. They also have a beta feature flag for blocking Passkeys but allowing physical keys (which they do not guarantee success)
Are there any widely-used sites that actually enforce attestation?
I seem to remember that apple specifically don't provide attestation details on their implementation.
Basically put it there for nerds and IT where the device owner wants that extra security and coordinates with (or is) the service provider to set it up. For everyday use, it should be unavailable so that it's not used for lockin.
Whether or not attestation data is passed onto the browser is a decision the passkey provider can make.
The spec allows for hardware attestation as well, to ensure passkeys are being provided from blessed computing environments. Hopefully implementers continue to ignore this anti-feature, because it's entirely stupid to lock out users who want to control their own security; at the same time, letting anyone with an Android phone restore passkeys from the cloud with one of their device PINs.
https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
The credential exchange changes nothing IMO, the rod to punish anyone who doesn't want their credentials stored on a tech giants servers is still there.
This is something that has been proposed that Tim fought against but mentioned in the thread to provide context of the types of kneejerk reactions the spec authors have had to push back against.
> (which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations)
I read "these situations" to mean "non-spec-compliant providers", where "spec-compliant" means to prevent plaintext export of resident keys.
Then watch them get hacked through a systems management plugin like Clownstrike, or Solarwinds.
Certainly a password manager like keepass would be no more complicated than trying to explain to her that she can no longer access her account because she broken her phone.
- Password is a single key, while passkey is a key-pair (private key & public key).
- Password can be weak, while passkey is always strong.
Password can be strong, if autogenerated.
- When authenticating, password can be send to the server (depending on the authentication protocol; SCRAM or PAKE based protocols never send password to the server). With passkey, private key is not send to the server for authentication purposes.
- Password manager can sync/backup your password and your passkey's "private" key.
- For a single service, same password is used from all devices. Passkey can be different for each device, but I'm not sure how this works (if it works) with sync/backup.
- Quantum-Safety: Key-derivation functions used with passwords are quantum-safe. Most (all?) asymmetric key algorithms, currently in commercial use (passkeys included), are not quantum-safe.
I'm not an expert on the topic. That's just a summary of my current understanding of passkeys, if it helps anyone. Note that mistakes are possible.
Per-machine passkeys would ostensibly be better hygiene, but only if I somehow kept them unsynced (easier said than done if you’re using Keychain). Having to manage that process would probably be more mistake-prone than just using the single passkey from my encrypted 1Password store.
For example, if user has two devices with same password manager. To sync per-machine passkey from 1st to 2nd device, the password manager would have to initiate authentication with the service on the 2nd device and confirm it from the 1st device. I guess this process could be fully automated.
The advantage is that this enables disabling passkey for a specific device. If a device is stolen, a password/passkey manager could be used to disable all passkeys tied to that device.
Another advantage is that a private key doesn't need to be shared with a third-party. A cloud service provider doesn't need to ever see your private key, unless you also want to have a cloud based backup. But the passkey backed on the cloud would need to be an unique keypair and maybe even have a different authorization policy (e.g. requiring another authentication factor when using it).
The ideal auth system makes use of both, with the passkey or hardware token as the MFA component and a strong passphrase as the traditional password component. In this way, you are protected from phishing, which is the final weak point that MFA methods like TOTP do not address.
Unfortunately, globocorps are pushing for passkeys as the sole means of authentication, rather than just the MFA component. Being cynical, I'm guessing they're doing this to facilitate some kind of vendor lock-in or fingerprinting.
Earlier this year I almost lost a domain because $REGISTRAR forced 2FA and I had forgotten to add them to my key spreadsheet.
IIUC basically these devices contain one single immutable random secret that is stored in a tamper proof hardware and can never leave the device nor be written into another device.
When you "create" new keys what actually happens under the hood is that a new value gets stored in flash memory which is the _combined_ with the hard secret with some key derivation scheme and the resulting secret is then the one used to perform cryptographic operations
You're correct about how key creation works as well AFAIK.
You can already use your phone today to store secrets with an acceptable threat model.
People lose credentials all the time, from social security cards, to drivers licenses, and passports. Say a natural disaster hits and your laptop with Yubikey gets swept away in a flood? Congratulations, you're hosed!
Individual people do not have the resources that a financial institution has. Getting people to adopt unique passwords is already an incredible hurdle, getting people to treat a hardware token literally more carefully than their social security card is bizarrely out of touch with reality.
As for me, I use Keepass to store my Passkeys. I use a password and Yubikey to secure it. The Yubikey has the same exact private keys set as 2 others, so I can keep 1 on my keychain, 1 in my safe, and 1 at a relative's house. And even this would be an unreasonable effort to expect from the majority of people.
It is and it is why Yubikeys are useless for most cases outside of the workplace.
I do not want a remote "authentication provider".
I have already had to replace two Yubikeys for the aforementioned reasons, so FIDO hardware token migration is a very real scenario that desperately needs to be addressed.
Also mind that there are too many services that allow you to only use one FIDO token, or even worse, only one primary 2FA method in addition to backup codes.