> 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.
KeepassXC actually supports passkeys and can be a passkey provider in a desktop browser.
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.
Can confirm: Using Android 14 and Bitwarden, I can sign in to github.com using my passkey. It pops up a system dialog where I can select Bitwarden and then my Github username.
Last time I checked, the Bitwarden Vault export included the whole FIDO credential including the private key.
Bitwarden (and Lastpass, iirc) support passkeys a little longer than KeePassXC. I'm glad to hear they achieved full integration.
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.
Idk I just set up both - email&password which live in my password manager and then passkeys for convenience - I can just hit a button without thinking and I’m in.
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…
I already hit a button (the Bitwarden icon in my browser toolbar) so I do not see what passkeys buy me, except a terrible hassle the day I want to change password manager.
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.
> 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.
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.
>> All passkey sites also support fallbacks to just password or other auth mode.
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?
It is by necessity; at the very minimum, you’ll need an OTP via email, since you need an out-of-band method of identifying the user during the registration.
I actually built a small web application that’s entirely passwordless, and it works really smoothly. I don’t get the antipathy towards Passkeys.
My antipathy stems from my lack of understanding, I freely admit, but it's a lack of understanding that's despite some modicum of intelligence.
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.
> 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.
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.
Passkeys are like SSNs, drivers licenses, passports, local phone numbers etc.:
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.
A lot of people here seem to ramble about this, apparently without ever having actually used Passkeys themselves: They are nothing like SSNs, driver licenses or other static IDs. A Passkey is generated per device/site combination, where the client holds the private key, the site receives the public key, and the user can optionally share their private key among user devices depending on their client software. That's all it is. How are you "screwed", and what does it even mean "they don't work perfectly" for you?
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.
I dunno. Should we then proceed to keep up the awful situation we currently have for the 99%, just to avoid any inconvenience to the 1%? That's not how democratic societies usually work.
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?
As I said: Most likely the ideal solution really is passkeys, just not in their current form.
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.
That’s exactly the concern many people here have with passkeys in a nutshell:
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).
This is an exceptionally cynical take. WebAuthn is an open standard; this new credential transfer spec is the opposite of “big vendor lock-in”. It’s standardising the export-import.
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.
> 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.
> FIDO Alliance’s credential exchange specifications define a standard format for transferring all types of credentials in a credential manager including passwords, passkeys and more in a manner that is secure by default.
The hint of why this may be just slightly complicated is in that final phrase.
> 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
SSH keys are a massive security liability. A private key, readable by any process you execute, without you noticing, that acts as a key to the kingdom? Maybe protected by a weak passphrase - since you probably have to enter that often - an attacker can brute force at their own discretion after copying it? A heap of public keys belonging to god-knows-which-machine, copied manually to every other server?
Designing a system that is secure, scalable, and works for billions of people worldwide in a highly adversarial environment is freaking hard.
> A private key, readable by any process you execute, without you noticing, that acts as a key to the kingdom?
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.
Personally, I've never met a cloud provider I would trust with holding my secret tokens. It just seems like such a juicy target for hackers. You have to trust that they have done everything right all of the time.
> 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.
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?
Unlike your photo collection, passkeys aren’t precious. They’re just meaningless data. You can and should generate additional ones for each password manager you use, so you have multiple independent ways of getting into an account. As long as you can do that, everything is replaceable and there’s no lock-in.
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.
For this to be practical, there needs to be a way to enroll non-present devices. Which is technically feasible, but there's no real support for it yet in the standard or in the available implementations. (e.g. with SSH you can have a list of the public keys of all your devices). That would make e.g. passkeys on a HSM more feasible, since you could enroll your backup in a safe whenever you create an account with your daily driver one.
(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)
The proposal that any time o create an account o need multiple physical tokens or multiple password managers running is unbelievably stupid & fantastical. This whole project is doomed doomed doomed of this is the model.
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.
I bring it up because people claim there is lock-in and it’s not true.
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.
> 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
Choose a passkey provider that supports this then. I use bitwarden. Other people use iOS keychain. Both work great.
I know you’re applying the same model as for SSH keys (and functionally they are very similar) … but I also think 1 SSH key/device is impractical if you have many services to log into and many devices to log in from - which is just the reality nowadays.
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.
It's not particularly impractical for SSH: have a text document with the public keys of all your devices, and copy it into the authorized keys for any system you want to log into. Passkeys don't have an analog for this, though.
> 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.
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.
Fwiw, I have two phones (work and personal), two tablets (ipad and Android), 4 laptops (primary employer, client, personal, music productions), one main desktop for gaming, 4 intel nuc for various TV's and whatnot around the house and two Intel nuc for experimenting. Plus my wifes stuff.
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:)
AFAIK, you can register your passkeys using your own provider (eg. Bitwarden). I’ve not personally used it too much, but the option is there.
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.
Do you use the same SSH keys on multiple devices? I certainly don't. If you need or wanted to (you don't) you'd need some way to sync them across multiple devices securely.
When I use passkeys on a single device, the "provider" is the OS, same as with my SSH keys.
> Do you use the same SSH keys on multiple devices?
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
> And you have full access to ~/.ssh and you can move copy update rename delete them however you like.
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).
> Do you use the same SSH keys on multiple devices?
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.
Haha technically true, but I don't think that was the kind of device they were referring to. Even so, it is possible to use the same key on multiple yubikeys. You generate a PGP key on a secure computer and then load that key onto multiple yubikeys. Then you use gpg as your ssh agent. But this is less secure than using keys generated on-device by the yubikey because your private key exists (hopefully temporarily) as a file on the computer where you generated it.
No this is absolutely what I meant: A passkey and a PGP key function very similarly in this capacity, a passkey for a site can be generated on a yubikey and used across devices in just the same way.
You don't. Same as a physical key for your home, you have 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.
> Do you use the same SSH keys on multiple devices?
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.
- 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.
Re you not being sure how sync would work with multi-device passkeys, you can share a passkey between devices with 1Password, Apple’s Keychain, etc, and use it to log in from any of them. I typically do this rather than manage them per-machine.
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.
Yeah, multi-device passkeys are easy to sync. Per-machine passkeys sync would be interesting, as it could not just copy the private key (as then it wouldn't be per-machine anymore), but would need to generate a new passkey for each synced device.
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.
I'm super curious how this will ultimately work. As noted in another thread, secure enclaves aren't secure if they can be copied. Such that, if this is moving the passkey by copying it, I'm not at all clear on how that stays secure?
Generally this spec is talking about the kind of passkeys that are stored in password managers, not the kinds used by hardware security keys. Those in a password manager have always been technically copyable somehow, there just wasn't a standard format or protocol for doing so.
I knew that "passkey" had grown to refer to a set of different things. I can't say this upsets me, as it does sound like progress over the old status quo. Still, is confusing for those of us that bought in at the beginning.
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 terminology is definitely a mess, but I believe at least “passkey” has never referred to hardware authenticators. Those were usually called “security keys” or similar.
Agree. Passkey should be reserved for credentials that can be synced or exported to different providers, as this is what is most analogous to a password from a user perspective.
There should be a different standardized term used for hardware bound keys. So users wont get confused.
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.)
Fair, but if the secret is exportable, then it loses a ton of its power.
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?
Does this include a way for a technically-savvy user to 'repatriate' their passkeys into their own infrastructure? (i.e. If I want to be my own provider)
I would also be concerned about whether you can recover when a provider becomes unusable or hostile, and there is no cooperative migration path.
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.
Can you not just set up a new passkey using a different provider (eg. Bitwarden)? It is a bit inconvenient, since it has to be done manually for every site.
That seems scary, I think I’d rather move them over one by one and delete the old passkey/2fa. I want to make it as hard as possible to keep them from being moveable as that’s one less attack point for hackers.
How does this suddenly become a problem when as the user I want access to my keys, but it isn't a problem when corporations copy my keys between them, which is what this post is about?
In that case, the keys would be a non-starter. The overwhelming majority of tech requests relate to people forgetting their passwords and getting in trouble because the browser's password manager forgot the password itself.
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.
The exchange spec suggests that the sending secure enclave sends encrypted credentials to the receiving secure enclave; they're never unwrapped in public between 'trusting' enclaves; which enclaves will trust each other enough to perform the credential transfer is another question.
The worst thing about passkeys is how browser extensions must handle them: using JavaScript injections to the web page. Of course this means _any_ browser extension could do the same and be the man-in-the-middle inspecting the passkey creation and authentication.
I'd be glad to have some kind of standard API behind a proper permission for handling passkeys.
The only thing that they should be able to intercept there, though, would be the specific passkey for the page you are authenticating with. With the specific challenge that was included, even. Such that it is not exportable to somewhere else for them to authenticate as you.
Sure, it sucks that anything is interceptable. But this is still an improvement over the status quo.
Something that is not clear to me about passkeys and makes me uneasy to start using them:
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?
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.
This exactly where my distinction about "what the passkey actually is" is important: if it's only a password, then I assume I can do the recovery. Whereas if it's 2FA, I assume I can't.
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 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.
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.
It's a problem for anything where you need to manually keep backups of key material. It's why so many cryptobros lost millions (billions?). If you expect the average person to keep their passkey backup stored well enough to avoid the possibility of physical disaster or losing access to their Google Drive, you've set them up for failure. And when the stakes are losing access to your online life, that's a catastrophic design flaw.
I'd give a key to my bank that they could create signatures with if I asked for (and was authenticated with) that third parties could trust to bypass my passkey. I'd pay a fee for it, the bank holds liability for verifying my identity.
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.
Minor correction (I'm assuming it was a typo) -- the secret for the passkey should be the private key. The server stores the user's corresponding public key.
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.
> Minor correction (I'm assuming it was a typo) -- the secret for the passkey should be the private key
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.
Two main ways: first, as I said in my original comment, you don't reveal the key when you use a passkey. So at worst a phisher might be able to get you to sign a challenge that they are facing to get into your account once, but they would not be able to re-use your credentials to get in again or to get into another site. And second, in a proper implementation you would have a separate key for every site you want to authenticate to, so a phisher would not have to merely phish you, they would have to mount an MITM attack on an HTTPS session (or find some other way to impersonate the site they are trying to phish your credentials for). That's not impossible, but it's orders of magnitude harder than impersonating a site through a typosquatting attack.
So, it really doesn’t prevent phishing. If you can get someone to give you their password, you can probably get them to click approve. The real benefit is to the service provider, not having to worry about leaking a secret if they get compromised.
They would have to get you to install a malicious version of your web browser and/or passkey manager, as all legitimate implementations enforce having the correct TLS domain, which is significantly harder than getting you to visit a random URL.
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.
If you got tricked into logging into goggle.com or something the FIDO2 auth would fail because a) the URL would not match the credential metadata and b) the resulting assertion, a signature over data which includes the URL, would not be valid (google.com would not accept it).
"Hi, this is Bob from blah support, we need to confirm your account is a correct. When prompted please confirm to give us access". if someone is dumb enough to hand out a password, they are dumb enough to click approve. Phishing is a social attack, not a technical attack.
Your passkey provider will simply refuse to show that it has a credential for Bob's phishing convincing phishing site. RP challenges are bound to a domain for this purpose.
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.
It depends on your security risk profile and the type of passkey provided. The passkey's response describes if the credential is transferrable or not, and if the user has been positively verified as present.
They're as secure as having your password + 2FA in a password manager.
Should be noted that there's still debate on user presence, to the point that someone submitted a CVE[0][1] on KeePassXC for not abiding by this part of the protocol (and which I take Keepass's side).
A key difference between a passkey and a password is that a passkey is never transmitted off of your device. The existing tech that they most resemble is ssh keys.
How does Google Password Manager sync your passkeys then?
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]
> Private key is not transmitted off of your device when authenticating.
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.
And the interaction between the thing that generates the passkey and my password manager is very confusing. I got multiple popups and it wasn’t completely clear which was chrome ans 1password.
Strictly speaking, passwords do not have to be shared during auth, either. There are password-agreement schemes (e.g. SRP [1] as used in TLS-SRP) which allow one or both parties to prove they know the password without sharing it. However, these schemes never gained broad adoption.
It's easy to have your keys backed up to a device, but then the question becomes losing the device and being able to get back into a new one. I know that Google really, really likes to make sure it's you when you log in from an unexpected device, location, IP, etc, and it might be hard to prove that it's you without that one device.
> The other thing is that multiple keys can be created.
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.
A FIDO2 credential can be used for passwordless authentication, so long as the authenticator performs user verification (e.g. requires a PIN). This counts as 2FA because it's something you have (the authenticator) plus something you know/are (PIN/biometric).
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.
If the passkey is all you have, then you're doomed (at least to the extent of whatever alternative recovery procedures the vendor is making available to you). That's why it's pretty universal to provide backup codes to put in your safe when setting up a passkey.
While better in many ways, broadly speaking this could mean no more throwaway accounts?
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.
No, a site can require attestation that you are on a kind of device but it can't correlate a key you have registered with it with one you create for any other site.
Right, but I imagine most sites will continue to use third-party authorization for passkeys, similar to Okto, Auth0, et al? They'd even be incentived to do so if it meant more granular user profiling -- all alongside third-party guarantees of "real verification", etc.
What 3rd party password/passkey manager you use is not the business of a site unlike when they list allowed single sign-on OAuth vendors.. And using the managers is an alternative to using a secure enclave correctly.
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.
Passkeys are terrifying, and I don’t understand why the companies pushing them are doing so. What are their motives? What do they gain from catastrophically increasing the risk that users completely lose access to our ability to conduct our lives?
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.
I mean, isn't the idea from them that you have 2 or more of them?
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
> I mean, isn't the idea from them that you have 2 or more of them?
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?
As any kind of key you need to be able to replace them after you lose them (think of a flood or a house fire) so either:
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.
Isn’t the whole point of a passkey that it’s meant to use a chain of trust to prove that you’re you via biometrics or a physical factor? I’ve read that they’re intended to remove the need for 2-factor authentication because they are both factors, which implies you shouldn’t be allowed to reset them.
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.
My keychain has two physical keys, and these change only every time I move.
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.
> My keychain has two physical keys, and these change only every time I move.
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.)
> How often they change is irrelevant, the point is how you would recover them.
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.
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.
I’m already using a password manager. I struggle to see the security benefit to storing passkeys in them.
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.
As a counter-point, my SSH keys are bound to my laptop's secure enclave and it's not possible for me to back them up.
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.
That was basically what I was going to say too. The most secure keys are the ones that can't be transferred. If I want protection against the loss of a hardware security key like a Yubikey, I have to get a second one and register that one as a secondary key to log in.
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.
To be fair, the webauthn spec expressly forbids facilitating the extraction of credentials from the authenticator (though arguably even syncing between devices violates the spec).
That's not a backup, that's just another secret. If I can't record the secret onto paper that I can put in a safe deposit box at a bank (or several), then it ain't backed up.
It’s an equivalent key. It unlocks the same door. It doesn’t matter if it’s the same bits, because the only thing we care about is whether it unlocks the door.
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.
No. How do you use it if it's in a safe? The only way this works is if you use the yubikey to log into google or some other auth provider and then use that auth provider for everything. But you are even worse off then as that auth provider now is a single point of failure... get that account revoked for any reason and you've lost access everywhere.
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.
But why do THAT when what were asking for is control over our own data, our own secrets? Because it's imagined to be "less secure"?
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.
This is good. One thing holding me back from fully embracing passkeys has been the inability to export passkeys in a format that I can store in a way that suits my preferences. This should solve that. Well, at least 1Password claims it will...
In one of the things that I do in my job, I run the auth system for a fintech, and passkeys are an incredible step forward for the typical user. Being able to migrate your passkeys between providers is a great step forward, I'm glad this is being implemented.
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.
> If anyone in the comments doesn't like the implementation of webauthn, suggest changes to the spec
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.
Requiring MDM for attestation seems like the extremely-obvious answer to all this, yea.
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.
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.
You missed the rest of that sentence from your quote. It's an open spec, suggest changes to the spec, not me. I didn't write it. I actually agree you should be able to use whatever device you want. I'm a relaying party and I don't require attestation.
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.
> If anyone in the comments doesn't like the implementation of webauthn, suggest changes to the spec
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.
Again, ya’ll are living in a different world. Passkeys doesn’t have to support your use case, you’ve already got FIDO 2 keys for this. Physical keys have been readily available for over a decade from yubikey and the market penetration for consumers is basically zero.
I understand your enthusiasm for passkeys and I think there are real benefits, especially for non-technical users. But likewise, there is also enthusiasm for the objectively more secure hardware tokens. Residential keys are a problem for hardware tokens.
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.
It's not just needing to remember user names, is everyone in this thread just willfully ignoring what I've been saying about needing multiple (privacy incompatible) channels of data to be able to trust these login methods that aren't passkeys?
So, ruin a thing that works for a few people (and arguably was the primary target of the spec before big tech essentially took it over) for no reason other than marginal relying party convenience?
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.
> With resident keys? A couple dozen, if you're lucky.
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.
You still need to allocate physical space for 1) the cryptographic circuitry of the token 2) the tamperproof and stress-resistant enclosure. Depending on the form factor, you might not have that much physical space left for storage. The physical requirements for a token are much more complex than a plain USB drive.
Yes, exactly. Resident keys take up storage space. This article that was updated 5 months ago says that the most recent yubikey can support up to 100 discoverable credentials: https://support.yubico.com/hc/en-us/articles/360013790319-Ho... That might sound like a lot, but given that we want to achieve a migration to passwordless across the internet, you will quickly run out of storage space if every shop on the internet wants a dedicated keypair on your device.
Non-resident keys are so much better, because you won't need to worry about this limitation.
> I use passkeys for everything I can and I've never once seen friction.
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.
The thing you have to factor in is that most people are at risk of phishing or password leaks by compromised sites. The vast majority of users don’t have the problems you mentioned so it’s a question of whether we should leave 90% of users at risk or let them have a safer, easier, faster experience while the remaining people continue doing what they are doing now or drop a few bucks on hardware tokens.
There are already different specs for hardware tokens, if there was adoption by consumers people like me would support them, but there isn’t. Hell I was an early yubikey user as a consumer myself, but the utility was never there because there was so little adoption by regular people.
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
> 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.
I'm with you on device local keys with attestation.
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.
I find it silly and backwards to implement this. One has a private key and one could use it to act as a ~CA attesting for the establishment of another key with the relying party. Then one would always know what the hell happened when keys inevitably end up getting compromised by the poor practices of some of the vendors.
It's clearly a compromise, but if we were going for a perfect implementation then everyone would have a local/self hosted soloution. This just means in the case of a bad vendor/unwanted default/change to a better vendor you can migrate away from them quickly (and not need to visit them again) without having to update all your pass keys at once.
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.
Leaving everyone finding the custom way to update/add a passkey when the fix for that would prevent sharing keys and needing to manually do something 100-1000 times to regain a little security.
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?
I only need one provider. A portable open source encrypted database I'm in control of and can back up and secure as needed. It's what I have now, and have had for years, in my password manager. I won't be at the mercy of a company or a device to access my digital life.
That's cool, but the last thing I would want my mom to have to manage is a portable open source encrypted database shes's in control of and can back up and secure as needed.
There are FIDO Alliance folks posting Github issues requesting to remove features such as plaintext exporting of credentials, with the explicit threat that the Alliance might block such "open" passkey providers in the future. A local database is not enough, it needs to be locked in a secure element or protected with some TPM-like scheme.
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.
Pretty telling thread. Tim Cappalli, one of the spec writers drops by to criticize the export feature and suggests that the attestation feature should be used to punish them for not implementing the fully locked in version.
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.
I halfway expect a v2 specification where keys are only stored on a few "Certified Attestation-capable" providers (i.e. facebook, google, apple, amazon)
Then watch them get hacked through a systems management plugin like Clownstrike, or Solarwinds.
That's not what happened. He said quote "which would allow RPs to block you, and something that I have previously rallied against".
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.
Currently it is not. It was created provider centric so far, and in my reading of the spec, a thinly veiled lockin. The ability to move around should have been built in from the beginning but it was more beneficial for the providers to start without.
Historically, the spec was written for hardware security tokens. Keys on those tokens can't be moved around by design.
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.
The attestation anti-feature which is part of the spec. And the portability feature which is conspicuously not. The former makes the enforcement of the later possible.
The attestation is part of the webauthn spec, and it's up to the relying party to decide whether or not to use it. The whole reason it's there is to give some contexts the ability to narrow their users down to specific webauthn storage implementations (which is useful in some corporate / gov contexts).
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)
OK, so you gave two examples of systems that do NOT enforce attestation (one that is not in production, one that has an option to enforce attestation but is not apparently in use).
Are there any widely-used sites that actually enforce attestation?
People already do have issues with e.g. banking apps on mobile devices requiring OS attestation, so we can expect that once they know they can do the same for the most of their web clients (so probably once most people have moved onto Windows 11 which requires a TPM), they will.
It’s absurd, really. Attestation is clearly a feature intended for high security environments, where you want to ensure all employees use their corporate hardware authenticators and those only, yet people act like it’s big techs secret, evil mind control back door.
As a sibling comment explains, attestation isn't processed by common web browsers unless explicitly configured. Your bank can require attestation from you and limit you to a number of supported authenticators... But I don't quite see what that would get them, other than loosing customers? And to what end, to foster ecosystem lockin on behalf of Apple or Google? It doesn't make any sense. Hence: absurd.
Non-default as in browsers should not provide any attestation information unless configured to via a setting in about:config (which can be automatically enabled by IT on a managed device), and mobile OSes should not provide attestation info to apps unless configured via some similarly buried setting that MDM can enable.
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.
Given the chance, why wouldn't companies abuse that feature like every single anti-user feature in the history of them? Surely this time it will be different?
The regulatory universe that banks operate in means that they're not like other companies. They don't share the same overall incentives, and aren't a useful point of comparison.
It's only a matter of time when it's this easy. Some essential service, most likely a bank, will inevitably turn it on in the future. And it only takes one of those to make all freedom respecting providers non-viable for someone. For our safety, of course. :)
My mum has a password notebook which is locked away in a drawer in her house, she knows to use either passphrases or random string that her browser generates for her. For her threat model this is better than any software thing.
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.
I think the whole point of yubikeys is to make this impossible.
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
Yes, but nothing prevents someone from making a hardware security token that has a copyable memory. Some people will have a threat model where this is acceptable.
This is yet another security measure that completely ignores the real world and will become yet another security measure that gets ignored.
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.
The recommendation is to use two keys or to always have an additional backup method configured. So you should never be in a position where a migration is required.
Hardware tokens are physical objects that are subject to mechanical wear and tear and can be lost. Hardware tokens are also subject to ending up on a hardware attestation blacklist because of security weaknesses.
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.
I came across an opinion I largely agree with: https://mastodon.social/@lapcatsoftware/113308133338196824 and https://mastodon.social/@lapcatsoftware/113308273654667583
> 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.
So it's not just me!
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.
KeepassXC actually supports passkeys and can be a passkey provider in a desktop browser.
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.
Can confirm: Using Android 14 and Bitwarden, I can sign in to github.com using my passkey. It pops up a system dialog where I can select Bitwarden and then my Github username.
Last time I checked, the Bitwarden Vault export included the whole FIDO credential including the private key.
Bitwarden (and Lastpass, iirc) support passkeys a little longer than KeePassXC. I'm glad to hear they achieved full integration.
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.
> Android 14 seems to allow changing the passkey provider in the android system as well
It's worth noting this is also supported in iOS and macOS.
Settings > General > AutoFill & Passwords
Idk I just set up both - email&password which live in my password manager and then passkeys for convenience - I can just hit a button without thinking and I’m in.
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…
I already hit a button (the Bitwarden icon in my browser toolbar) so I do not see what passkeys buy me, except a terrible hassle the day I want to change password manager.
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.
Passkeys work fine with password managers like 1Password, KeePassXC, Bitwarden and others, why do you keep repeating this walled garden shtick?
They're literally a cryptostring stored in your password manager just like your other passwords.
Have you ever migrated one across password managers yourself? I tried; it currently seems impossible.
> 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 copy paste them using those formats. What are you arguing about here actually?
How does one get a passkey from iCloud into one of these formats?
"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".
Apple actually does allow airdropping passkeys across devices and iCloud users!
It’s clearly not (just) a security but a lock-in feature.
With Keepass you can, at least. Other ones not so much.
> 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.
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.
>> All passkey sites also support fallbacks to just password or other auth mode.
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?
It is by necessity; at the very minimum, you’ll need an OTP via email, since you need an out-of-band method of identifying the user during the registration.
I actually built a small web application that’s entirely passwordless, and it works really smoothly. I don’t get the antipathy towards Passkeys.
My antipathy stems from my lack of understanding, I freely admit, but it's a lack of understanding that's despite some modicum of intelligence.
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.
> 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.
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.
You have an incomplete threat model. What passkeys bring that is new to the table is phishing resistance, when the user is the one that is breached.
Passkeys are like SSNs, drivers licenses, passports, local phone numbers etc.:
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.
A lot of people here seem to ramble about this, apparently without ever having actually used Passkeys themselves: They are nothing like SSNs, driver licenses or other static IDs. A Passkey is generated per device/site combination, where the client holds the private key, the site receives the public key, and the user can optionally share their private key among user devices depending on their client software. That's all it is. How are you "screwed", and what does it even mean "they don't work perfectly" for you?
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 know how they technically work.
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.
I dunno. Should we then proceed to keep up the awful situation we currently have for the 99%, just to avoid any inconvenience to the 1%? That's not how democratic societies usually work.
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?
As I said: Most likely the ideal solution really is passkeys, just not in their current form.
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.
Yeah, they're more like SSH id_rsa/id_rsa.pub keys you've probably been using for decades.
That’s exactly the concern many people here have with passkeys in a nutshell:
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.
No, this is not guaranteed.
They are different from passwords in that they are never send over the web. They are a private key used to sign a challenge from the site.
The private keys are not sent to the relying party yet TFA is about a spec to send them over the web.
> They're in no way different than that random password stored in your password manager
Except in all the ways that matter: they are not accessible to users, they are tied to third-party vendors.
That's an outright lie now, isn't it?
I’ll answer your question with a question: can you memorise your passkey for a given website?
With a draft standard that we have no way of knowing Google and Apple will implement?
The second one is particularly pertinent:
> Passkeys are essentially site-specific cryptographic keypairs, which are fine, combined with big tech company paternalism, which is intolerable.
This is an exceptionally cynical take. WebAuthn is an open standard; this new credential transfer spec is the opposite of “big vendor lock-in”. It’s standardising the export-import.
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.
> This is an exceptionally cynical take.
> 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.
> 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.
That's a bit like saying a house fire is what makes your deleted files uniquely safe from recovery.
The sentence is true, as far as it goes... But it's uniquely excessive, rather than the unique minimum sufficient for the task.
> FIDO Alliance’s credential exchange specifications define a standard format for transferring all types of credentials in a credential manager including passwords, passkeys and more in a manner that is secure by default.
The hint of why this may be just slightly complicated is in that final phrase.
> 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
SSH keys are a massive security liability. A private key, readable by any process you execute, without you noticing, that acts as a key to the kingdom? Maybe protected by a weak passphrase - since you probably have to enter that often - an attacker can brute force at their own discretion after copying it? A heap of public keys belonging to god-knows-which-machine, copied manually to every other server?
Designing a system that is secure, scalable, and works for billions of people worldwide in a highly adversarial environment is freaking hard.
> A private key, readable by any process you execute, without you noticing, that acts as a key to the kingdom?
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.
But that's exactly my point; securing SSH keys properly is hard to do right at scale, and Passkeys are a solution to manage key pairs at scale.
Personally, I've never met a cloud provider I would trust with holding my secret tokens. It just seems like such a juicy target for hackers. You have to trust that they have done everything right all of the time.
> 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.
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?
Unlike your photo collection, passkeys aren’t precious. They’re just meaningless data. You can and should generate additional ones for each password manager you use, so you have multiple independent ways of getting into an account. As long as you can do that, everything is replaceable and there’s no lock-in.
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.
For this to be practical, there needs to be a way to enroll non-present devices. Which is technically feasible, but there's no real support for it yet in the standard or in the available implementations. (e.g. with SSH you can have a list of the public keys of all your devices). That would make e.g. passkeys on a HSM more feasible, since you could enroll your backup in a safe whenever you create an account with your daily driver one.
(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)
The proposal that any time o create an account o need multiple physical tokens or multiple password managers running is unbelievably stupid & fantastical. This whole project is doomed doomed doomed of this is the model.
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.
I bring it up because people claim there is lock-in and it’s not true.
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.
> 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
Choose a passkey provider that supports this then. I use bitwarden. Other people use iOS keychain. Both work great.
I know you’re applying the same model as for SSH keys (and functionally they are very similar) … but I also think 1 SSH key/device is impractical if you have many services to log into and many devices to log in from - which is just the reality nowadays.
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.
It's not particularly impractical for SSH: have a text document with the public keys of all your devices, and copy it into the authorized keys for any system you want to log into. Passkeys don't have an analog for this, though.
fwiw https://github.com/<username>.keys is a pretty good one for that
> 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.
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.
It’s certainly not my reality. I have a desktop computer and a laptop that I use ssh from. How many computers do you have?
Fwiw, I have two phones (work and personal), two tablets (ipad and Android), 4 laptops (primary employer, client, personal, music productions), one main desktop for gaming, 4 intel nuc for various TV's and whatnot around the house and two Intel nuc for experimenting. Plus my wifes stuff.
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:)
AFAIK, you can register your passkeys using your own provider (eg. Bitwarden). I’ve not personally used it too much, but the option is there.
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.
> AFAIK, you can register your passkeys using your own provider (eg. Bitwarden).
Why should we even need a third-party provider? Imagine needing a third-party "provider" for your own ssh keys.
If you only want first-party, you can presumably implement the spec yourself and do whatever you want with the data?
My example was only to point out that there exist self-hostable passkey providers.
Do you use the same SSH keys on multiple devices? I certainly don't. If you need or wanted to (you don't) you'd need some way to sync them across multiple devices securely.
When I use passkeys on a single device, the "provider" is the OS, same as with my SSH keys.
> Do you use the same SSH keys on multiple devices?
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
> And you have full access to ~/.ssh and you can move copy update rename delete them however you like.
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).
> Do you use the same SSH keys on multiple devices?
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.
pedantic nit: the yubikey is a device so you are arguably using one unique key per device
Haha technically true, but I don't think that was the kind of device they were referring to. Even so, it is possible to use the same key on multiple yubikeys. You generate a PGP key on a secure computer and then load that key onto multiple yubikeys. Then you use gpg as your ssh agent. But this is less secure than using keys generated on-device by the yubikey because your private key exists (hopefully temporarily) as a file on the computer where you generated it.
No this is absolutely what I meant: A passkey and a PGP key function very similarly in this capacity, a passkey for a site can be generated on a yubikey and used across devices in just the same way.
I certainly backup my SSH keys. That way if my laptop dies today, I can be up and running tomorrow without anyone else being involved.
How do I ensure I can access my accounts if my phone-containing-passkeys is lost/stolen/dies without backups?
You don't. Same as a physical key for your home, you have 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.
> Do you use the same SSH keys on multiple devices?
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.
Password vs. Passkey:
- 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.
Re you not being sure how sync would work with multi-device passkeys, you can share a passkey between devices with 1Password, Apple’s Keychain, etc, and use it to log in from any of them. I typically do this rather than manage them per-machine.
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.
Yeah, multi-device passkeys are easy to sync. Per-machine passkeys sync would be interesting, as it could not just copy the private key (as then it wouldn't be per-machine anymore), but would need to generate a new passkey for each synced device.
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).
It's also not a one or the other kind of thing.
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.
I'm super curious how this will ultimately work. As noted in another thread, secure enclaves aren't secure if they can be copied. Such that, if this is moving the passkey by copying it, I'm not at all clear on how that stays secure?
Generally this spec is talking about the kind of passkeys that are stored in password managers, not the kinds used by hardware security keys. Those in a password manager have always been technically copyable somehow, there just wasn't a standard format or protocol for doing so.
I knew that "passkey" had grown to refer to a set of different things. I can't say this upsets me, as it does sound like progress over the old status quo. Still, is confusing for those of us that bought in at the beginning.
The Yubico FAQ explains some of the history fairly well: https://www.yubico.com/blog/a-yubico-faq-about-passkeys/
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 terminology is definitely a mess, but I believe at least “passkey” has never referred to hardware authenticators. Those were usually called “security keys” or similar.
Agree. Passkey should be reserved for credentials that can be synced or exported to different providers, as this is what is most analogous to a password from a user perspective.
There should be a different standardized term used for hardware bound keys. So users wont get confused.
Passkeys don't need to be hardware bound.
The (probably?) most widespread implementation of them (iOS + macOS et. al) isn't; they're synced between devices.
Passkeys aren’t identical with secure enclaves.
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.)
Fair, but if the secret is exportable, then it loses a ton of its power.
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?
Does this include a way for a technically-savvy user to 'repatriate' their passkeys into their own infrastructure? (i.e. If I want to be my own provider)
I would also be concerned about whether you can recover when a provider becomes unusable or hostile, and there is no cooperative migration path.
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.
At a minimum we will see if KeePass is a provider that is supported; they seem to be the only pw manager in town that respect user freedom.
KeepassXC already supports passkeys
I'm curious if you count Pass (https://www.passwordstore.org/) as not being "in town" or if it has issues with user freedom that I'm ignorant of.
Eh I should’ve qualified with pw managers that support passkeys.
Can you not just set up a new passkey using a different provider (eg. Bitwarden)? It is a bit inconvenient, since it has to be done manually for every site.
A bit is understatement. If this passkeys become widespread, we are talking about like 100 sites.
I have over 500 logins in my Bitwarden account right now. Many of those are not important in the least, but hundreds of them are.
If you go for passkeys, start putting them in your own provider from the start? Vaultwarden is a nice option.
That seems scary, I think I’d rather move them over one by one and delete the old passkey/2fa. I want to make it as hard as possible to keep them from being moveable as that’s one less attack point for hackers.
There shouldn't be. Secure enclaves aren't secure if they can be copied
How does this suddenly become a problem when as the user I want access to my keys, but it isn't a problem when corporations copy my keys between them, which is what this post is about?
In that case, the keys would be a non-starter. The overwhelming majority of tech requests relate to people forgetting their passwords and getting in trouble because the browser's password manager forgot the password itself.
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.
The exchange spec suggests that the sending secure enclave sends encrypted credentials to the receiving secure enclave; they're never unwrapped in public between 'trusting' enclaves; which enclaves will trust each other enough to perform the credential transfer is another question.
Passkeys and secure enclaves are only loosely related. You can implement one using the other, but it’s by no means a requirement.
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.
Secured against who?
So you are against this new spec becoming a standard then?
The worst thing about passkeys is how browser extensions must handle them: using JavaScript injections to the web page. Of course this means _any_ browser extension could do the same and be the man-in-the-middle inspecting the passkey creation and authentication. I'd be glad to have some kind of standard API behind a proper permission for handling passkeys.
The only thing that they should be able to intercept there, though, would be the specific passkey for the page you are authenticating with. With the specific challenge that was included, even. Such that it is not exportable to somewhere else for them to authenticate as you.
Sure, it sucks that anything is interceptable. But this is still an improvement over the status quo.
Something that is not clear to me about passkeys and makes me uneasy to start using them:
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?
> Are passkeys replacing passwords, 2FA, or both?
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.
> 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"?
Account recovery flows are generally entirely unaffected by the move from password to passkey.
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.
This exactly where my distinction about "what the passkey actually is" is important: if it's only a password, then I assume I can do the recovery. Whereas if it's 2FA, I assume I can't.
> Are passkeys replacing passwords, 2FA, or both?
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 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.
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.
But that's not a problem with passkeys, that's a problem with Firefox Sync.
It's a problem for anything where you need to manually keep backups of key material. It's why so many cryptobros lost millions (billions?). If you expect the average person to keep their passkey backup stored well enough to avoid the possibility of physical disaster or losing access to their Google Drive, you've set them up for failure. And when the stakes are losing access to your online life, that's a catastrophic design flaw.
> It's a problem for anything where you need to manually keep backups of key material.
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.)
I'd give a key to my bank that they could create signatures with if I asked for (and was authenticated with) that third parties could trust to bypass my passkey. I'd pay a fee for it, the bank holds liability for verifying my identity.
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.
OK, so your proposed alternative is to give a key to a trusted third party (TTP). But how do you authenticate to that TTP?
Minor correction (I'm assuming it was a typo) -- the secret for the passkey should be the private key. The server stores the user's corresponding public key.
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.
> Minor correction (I'm assuming it was a typo) -- the secret for the passkey should be the private key
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.
interesting. unfortunately i don't have as much awareness of ECC as i should have, thanks for the information.
I don't see how passkeys do anything to prevent phishing.
Two main ways: first, as I said in my original comment, you don't reveal the key when you use a passkey. So at worst a phisher might be able to get you to sign a challenge that they are facing to get into your account once, but they would not be able to re-use your credentials to get in again or to get into another site. And second, in a proper implementation you would have a separate key for every site you want to authenticate to, so a phisher would not have to merely phish you, they would have to mount an MITM attack on an HTTPS session (or find some other way to impersonate the site they are trying to phish your credentials for). That's not impossible, but it's orders of magnitude harder than impersonating a site through a typosquatting attack.
So, it really doesn’t prevent phishing. If you can get someone to give you their password, you can probably get them to click approve. The real benefit is to the service provider, not having to worry about leaking a secret if they get compromised.
They would have to get you to install a malicious version of your web browser and/or passkey manager, as all legitimate implementations enforce having the correct TLS domain, which is significantly harder than getting you to visit a random URL.
> you can probably get them to click approve
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.
Phishing relies on visual confusion to get people to enter their passwords on a site that isn't the one they think it is.
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.
If you got tricked into logging into goggle.com or something the FIDO2 auth would fail because a) the URL would not match the credential metadata and b) the resulting assertion, a signature over data which includes the URL, would not be valid (google.com would not accept it).
How exactly do you get someone to give their passkey private key to a bad actor?
"Hi, this is Bob from blah support, we need to confirm your account is a correct. When prompted please confirm to give us access". if someone is dumb enough to hand out a password, they are dumb enough to click approve. Phishing is a social attack, not a technical attack.
Your browser won't auth you with a key meant for a site you're not on. There's no mechanism for what you're describing.
Your passkey provider will simply refuse to show that it has a credential for Bob's phishing convincing phishing site. RP challenges are bound to a domain for this purpose.
Two things:
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.
So we still need a passkey + second factor, isn't that the case?
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
It depends on your security risk profile and the type of passkey provided. The passkey's response describes if the credential is transferrable or not, and if the user has been positively verified as present.
They're as secure as having your password + 2FA in a password manager.
Should be noted that there's still debate on user presence, to the point that someone submitted a CVE[0][1] on KeePassXC for not abiding by this part of the protocol (and which I take Keepass's side).
[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:
https://github.com/keepassxreboot/keepassxc/issues/10406
A key difference between a passkey and a password is that a passkey is never transmitted off of your device. The existing tech that they most resemble is ssh keys.
How does Google Password Manager sync your passkeys then?
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]
[0] https://support.google.com/chrome/answer/13168025
> Private key is not transmitted off of your device when authenticating.
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.
And the interaction between the thing that generates the passkey and my password manager is very confusing. I got multiple popups and it wasn’t completely clear which was chrome ans 1password.
Strictly speaking, passwords do not have to be shared during auth, either. There are password-agreement schemes (e.g. SRP [1] as used in TLS-SRP) which allow one or both parties to prove they know the password without sharing it. However, these schemes never gained broad adoption.
[1]: https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...
It's easy to have your keys backed up to a device, but then the question becomes losing the device and being able to get back into a new one. I know that Google really, really likes to make sure it's you when you log in from an unexpected device, location, IP, etc, and it might be hard to prove that it's you without that one device.
> The other thing is that multiple keys can be created.
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.
A FIDO2 credential can be used for passwordless authentication, so long as the authenticator performs user verification (e.g. requires a PIN). This counts as 2FA because it's something you have (the authenticator) plus something you know/are (PIN/biometric).
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.
If the passkey is all you have, then you're doomed (at least to the extent of whatever alternative recovery procedures the vendor is making available to you). That's why it's pretty universal to provide backup codes to put in your safe when setting up a passkey.
Account recovery flows are generally entirely unaffected by the move from password to passkey.
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.
Unfortunately that pattern negates many benefits of WebAuthN: That recovery code is phishable, can be captured by malware on the client or server etc.
you should have passkeys on at least two or three devices
How do you keep those devices synced? I have over 500 accounts in my password manager. Do I need to manually set up 500 * 3 devices?
You use your password manager to sync them.
Having one more thing to remember to do when I create a new account seems like the kind of tedious make-work computers should be automating.
I agree. The better answer from my view is to handle passkeys like passwords and manage them the same way.
While better in many ways, broadly speaking this could mean no more throwaway accounts?
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.
No, a site can require attestation that you are on a kind of device but it can't correlate a key you have registered with it with one you create for any other site.
Right, but I imagine most sites will continue to use third-party authorization for passkeys, similar to Okto, Auth0, et al? They'd even be incentived to do so if it meant more granular user profiling -- all alongside third-party guarantees of "real verification", etc.
What 3rd party password/passkey manager you use is not the business of a site unlike when they list allowed single sign-on OAuth vendors.. And using the managers is an alternative to using a secure enclave correctly.
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 they can be moved, they can be stolen. This'll boost acceptance, but also open a can of worms.
Passkeys are terrifying, and I don’t understand why the companies pushing them are doing so. What are their motives? What do they gain from catastrophically increasing the risk that users completely lose access to our ability to conduct our lives?
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.
> I don’t understand why the companies pushing them are doing so
> your entire digital existence is at the mercy of whatever device or technology platform you use to store your passkeys.
I mean, isn't the idea from them that you have 2 or more of them?
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
> I mean, isn't the idea from them that you have 2 or more of them?
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?
It isn’t but really should be. Apple requires you to register a minimum of two U2F keys if you use that as 2FA for iCloud.
As any kind of key you need to be able to replace them after you lose them (think of a flood or a house fire) so either:
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.
Account recovery flows are generally entirely unaffected by the move from password to passkey.
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.
Isn’t the whole point of a passkey that it’s meant to use a chain of trust to prove that you’re you via biometrics or a physical factor? I’ve read that they’re intended to remove the need for 2-factor authentication because they are both factors, which implies you shouldn’t be allowed to reset them.
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.
My keychain has two physical keys, and these change only every time I move.
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.
> My keychain has two physical keys, and these change only every time I move.
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.)
> How often they change is irrelevant, the point is how you would recover them.
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.
Account recovery flows are generally entirely unaffected by the move from password to passkey.
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 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.
Most sites that support passkeys only allow one passkey per account, and it’s never clear whether they do or not.
An argument can be made that a weaker security option that is used by more people is better than a stronger security option that is used by fewer.
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.
They can already be moved in proprietary ways. This just adds a standard one.
I had hope for passkeys, with all the interop-promises.
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.
> mainstream
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.
I’m already using a password manager. I struggle to see the security benefit to storing passkeys in them.
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?
As a counter-point, my SSH keys are bound to my laptop's secure enclave and it's not possible for me to back them up.
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.
That was basically what I was going to say too. The most secure keys are the ones that can't be transferred. If I want protection against the loss of a hardware security key like a Yubikey, I have to get a second one and register that one as a secondary key to log in.
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.
To be fair, the webauthn spec expressly forbids facilitating the extraction of credentials from the authenticator (though arguably even syncing between devices violates the spec).
If the vast majority of implementers (by users) are not compliant with a spec, that arguably says something about the spec as well.
if you can get a backup, someone can get scammed into providing that to an attacker, taking away any security benefit.
You can create backup keys by creating more passkeys.
I don't think that's really a workable solution.
That's not a backup, that's just another secret. If I can't record the secret onto paper that I can put in a safe deposit box at a bank (or several), then it ain't backed up.
It’s an equivalent key. It unlocks the same door. It doesn’t matter if it’s the same bits, because the only thing we care about is whether it unlocks the door.
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.
I understand the semantic difference but wouldn't you be able to say add a "backup" Yubikey and lock it in a safe?
Quite convenient when you need to create a new account...
No. How do you use it if it's in a safe? The only way this works is if you use the yubikey to log into google or some other auth provider and then use that auth provider for everything. But you are even worse off then as that auth provider now is a single point of failure... get that account revoked for any reason and you've lost access everywhere.
Why do that, though?
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.
My doors don’t change every other week. My set of passkeys does.
But why do THAT when what were asking for is control over our own data, our own secrets? Because it's imagined to be "less secure"?
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.
If you need (and therefore have) access to your safe every other week, chances are it’s not actually very secure.
This is good. One thing holding me back from fully embracing passkeys has been the inability to export passkeys in a format that I can store in a way that suits my preferences. This should solve that. Well, at least 1Password claims it will...
In one of the things that I do in my job, I run the auth system for a fintech, and passkeys are an incredible step forward for the typical user. Being able to migrate your passkeys between providers is a great step forward, I'm glad this is being implemented.
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.
> If anyone in the comments doesn't like the implementation of webauthn, suggest changes to the spec
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.
Requiring MDM for attestation seems like the extremely-obvious answer to all this, yea.
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.
Where are you still seeing attestation?
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.
You missed the rest of that sentence from your quote. It's an open spec, suggest changes to the spec, not me. I didn't write it. I actually agree you should be able to use whatever device you want. I'm a relaying party and I don't require attestation.
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.
> If anyone in the comments doesn't like the implementation of webauthn, suggest changes to the spec
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.
Again, ya’ll are living in a different world. Passkeys doesn’t have to support your use case, you’ve already got FIDO 2 keys for this. Physical keys have been readily available for over a decade from yubikey and the market penetration for consumers is basically zero.
I understand your enthusiasm for passkeys and I think there are real benefits, especially for non-technical users. But likewise, there is also enthusiasm for the objectively more secure hardware tokens. Residential keys are a problem for hardware tokens.
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.
It's not just needing to remember user names, is everyone in this thread just willfully ignoring what I've been saying about needing multiple (privacy incompatible) channels of data to be able to trust these login methods that aren't passkeys?
So, ruin a thing that works for a few people (and arguably was the primary target of the spec before big tech essentially took it over) for no reason other than marginal relying party convenience?
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.
> With resident keys? A couple dozen, if you're lucky.
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.
You still need to allocate physical space for 1) the cryptographic circuitry of the token 2) the tamperproof and stress-resistant enclosure. Depending on the form factor, you might not have that much physical space left for storage. The physical requirements for a token are much more complex than a plain USB drive.
Ideally you should not be able to determine whether a username is valid without authenticating.
> Resident keys essentially kill physical tokens.
Can you elaborate? I'm curious. Is there a storage problem?
Yes, exactly. Resident keys take up storage space. This article that was updated 5 months ago says that the most recent yubikey can support up to 100 discoverable credentials: https://support.yubico.com/hc/en-us/articles/360013790319-Ho... That might sound like a lot, but given that we want to achieve a migration to passwordless across the internet, you will quickly run out of storage space if every shop on the internet wants a dedicated keypair on your device.
Non-resident keys are so much better, because you won't need to worry about this limitation.
> I use passkeys for everything I can and I've never once seen friction.
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.
The thing you have to factor in is that most people are at risk of phishing or password leaks by compromised sites. The vast majority of users don’t have the problems you mentioned so it’s a question of whether we should leave 90% of users at risk or let them have a safer, easier, faster experience while the remaining people continue doing what they are doing now or drop a few bucks on hardware tokens.
There are already different specs for hardware tokens, if there was adoption by consumers people like me would support them, but there isn’t. Hell I was an early yubikey user as a consumer myself, but the utility was never there because there was so little adoption by regular people.
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
> 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.
I'm with you on device local keys with attestation.
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.
I find it silly and backwards to implement this. One has a private key and one could use it to act as a ~CA attesting for the establishment of another key with the relying party. Then one would always know what the hell happened when keys inevitably end up getting compromised by the poor practices of some of the vendors.
It's clearly a compromise, but if we were going for a perfect implementation then everyone would have a local/self hosted soloution. This just means in the case of a bad vendor/unwanted default/change to a better vendor you can migrate away from them quickly (and not need to visit them again) without having to update all your pass keys at once.
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.
Leaving everyone finding the custom way to update/add a passkey when the fix for that would prevent sharing keys and needing to manually do something 100-1000 times to regain a little security.
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?
What’s stopping providers from saying a collective “no” and forking the standard?
"and forking the standard" isn't necessary if you're not going to implement it.
I only need one provider. A portable open source encrypted database I'm in control of and can back up and secure as needed. It's what I have now, and have had for years, in my password manager. I won't be at the mercy of a company or a device to access my digital life.
That's cool, but the last thing I would want my mom to have to manage is a portable open source encrypted database shes's in control of and can back up and secure as needed.
Great; but, as long as a system supports the open solution, anyone can provide for you the closed one, while the opposite isn't the case.
And Passkeys is an open solution, what are you all going on about?
There are FIDO Alliance folks posting Github issues requesting to remove features such as plaintext exporting of credentials, with the explicit threat that the Alliance might block such "open" passkey providers in the future. A local database is not enough, it needs to be locked in a secure element or protected with some TPM-like scheme.
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.
The original thread:
https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
Pretty telling thread. Tim Cappalli, one of the spec writers drops by to criticize the export feature and suggests that the attestation feature should be used to punish them for not implementing the fully locked in version.
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.
I halfway expect a v2 specification where keys are only stored on a few "Certified Attestation-capable" providers (i.e. facebook, google, apple, amazon)
Then watch them get hacked through a systems management plugin like Clownstrike, or Solarwinds.
That's not what happened. He said quote "which would allow RPs to block you, and something that I have previously rallied against".
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.
Let's be truthful and show the remainder of that parenthetical:
> (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.
Currently it is not. It was created provider centric so far, and in my reading of the spec, a thinly veiled lockin. The ability to move around should have been built in from the beginning but it was more beneficial for the providers to start without.
Historically, the spec was written for hardware security tokens. Keys on those tokens can't be moved around by design.
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.
Passkeys are just resident webauthn tokens with a fancy name.
Where's the lockin?
The attestation anti-feature which is part of the spec. And the portability feature which is conspicuously not. The former makes the enforcement of the later possible.
The attestation is part of the webauthn spec, and it's up to the relying party to decide whether or not to use it. The whole reason it's there is to give some contexts the ability to narrow their users down to specific webauthn storage implementations (which is useful in some corporate / gov contexts).
Are there any examples of any widely-used sites that are enforcing attestation?
Two comes to mind:
- 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)
OK, so you gave two examples of systems that do NOT enforce attestation (one that is not in production, one that has an option to enforce attestation but is not apparently in use).
Are there any widely-used sites that actually enforce attestation?
People already do have issues with e.g. banking apps on mobile devices requiring OS attestation, so we can expect that once they know they can do the same for the most of their web clients (so probably once most people have moved onto Windows 11 which requires a TPM), they will.
It’s absurd, really. Attestation is clearly a feature intended for high security environments, where you want to ensure all employees use their corporate hardware authenticators and those only, yet people act like it’s big techs secret, evil mind control back door.
What is absurd about expecting companies to do what many internet banks in some countries already do?
As a sibling comment explains, attestation isn't processed by common web browsers unless explicitly configured. Your bank can require attestation from you and limit you to a number of supported authenticators... But I don't quite see what that would get them, other than loosing customers? And to what end, to foster ecosystem lockin on behalf of Apple or Google? It doesn't make any sense. Hence: absurd.
If it's only meant to be used for those environments, then attestation data should not be provided by default. IT can enable it on managed devices.
It's up to the provider as to whether they provide or not. I don't think there's a "default"?
I seem to remember that apple specifically don't provide attestation details on their implementation.
Non-default as in browsers should not provide any attestation information unless configured to via a setting in about:config (which can be automatically enabled by IT on a managed device), and mobile OSes should not provide attestation info to apps unless configured via some similarly buried setting that MDM can enable.
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.
Browsers should follow the spec.
Whether or not attestation data is passed onto the browser is a decision the passkey provider can make.
Given the chance, why wouldn't companies abuse that feature like every single anti-user feature in the history of them? Surely this time it will be different?
Because it’s highly annoying to set up in a way that doesn’t massively inflate your support cost.
This has not stopped banks in the past.
The regulatory universe that banks operate in means that they're not like other companies. They don't share the same overall incentives, and aren't a useful point of comparison.
It's only a matter of time when it's this easy. Some essential service, most likely a bank, will inevitably turn it on in the future. And it only takes one of those to make all freedom respecting providers non-viable for someone. For our safety, of course. :)
My mum has a password notebook which is locked away in a drawer in her house, she knows to use either passphrases or random string that her browser generates for her. For her threat model this is better than any software thing.
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.
Ok, but why should that stop me?
OK. Let me know when I can migrate FIDO credentials from old Yubikeys to new ones.
Earlier this year I almost lost a domain because $REGISTRAR forced 2FA and I had forgotten to add them to my key spreadsheet.
I think the whole point of yubikeys is to make this impossible.
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
> I think the whole point of yubikeys is to make this impossible.
It is and it is why Yubikeys are useless for most cases outside of the workplace.
Yes, but nothing prevents someone from making a hardware security token that has a copyable memory. Some people will have a threat model where this is acceptable.
you can technically do that but that would be a very confusing use of the name "hardware security token".
You can already use your phone today to store secrets with an acceptable threat model.
This is yet another security measure that completely ignores the real world and will become yet another security measure that gets ignored.
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.
Yeah whole point of YubiKey is that the physical key is REQUIRED and can't be cloned. So no, you won't be able export anything off of it.
You're correct about how key creation works as well AFAIK.
The recommendation is to use two keys or to always have an additional backup method configured. So you should never be in a position where a migration is required.
Hardware tokens are physical objects that are subject to mechanical wear and tear and can be lost. Hardware tokens are also subject to ending up on a hardware attestation blacklist because of security weaknesses.
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.
Yes. My other Yubikey is in a bank vault.
I do not want a remote "authentication provider".
If you want a Webauthn credential that you can "copy", don't use a Yubikey. Use something like KeepassXC, BitWarden etc. instead.