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.
Hardware-bound passkeys have always been copyable by the proprietary vendor.
Make a passkey on your Mac, it appears on your iPhone.
Make a passkey on your Android, it appears on your other Androids.
Anyone who can bind a new iPhone or Android to your Apple/Google account wins your passkeys. I think the only passkeys properly tied to hardware are dedicated FIDO devices.
By definition, if it can be copied out it wasn't hardware-bound.
Yubikeys are tamper-proof and cannot be copied. Everything else is just a place to store a statement that your cloud vendor of choice blesses this gadget to authenticate your account.
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.
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.
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.
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.
> 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.
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 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.
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.
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 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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
> 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.
> 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
Readit News
Make a passkey on your Mac, it appears on your iPhone.
Make a passkey on your Android, it appears on your other Androids.
Anyone who can bind a new iPhone or Android to your Apple/Google account wins your passkeys. I think the only passkeys properly tied to hardware are dedicated FIDO devices.
Yubikeys are tamper-proof and cannot be copied. Everything else is just a place to store a statement that your cloud vendor of choice blesses this gadget to authenticate your account.
The (probably?) most widespread implementation of them (iOS + macOS et. al) isn't; they're synced between devices.
They can be stored in them, but also in software; even when stored in hardware, they can be marked as extractable to some trusted party (a companion device with the same root of trust, a trusted cloud sync service, a supply chain attacker etc.)
If you are worried about state level activity, have it stored in a single place that can be compelled by law to disclose it and that is off the table for you.
Which, sure, you can argue that there are still hardware tokens for people. But that is itself a signal, no?
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.
Deleted Comment
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.
Deleted Comment
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.
Sure, it sucks that anything is interceptable. But this is still an improvement over the status quo.
> These big tech companies will do anything possible to prevent users from ever actually being able to access their own passkeys.
> Export and import should have been extremely simple. Instead, they took years to come up with some convoluted system where the only possibility is to transfer from one vendor lock-in to another vendor lock-in.
> With passkeys, the big tech companies are executing a coup d'état of authentication, just like they did for HTML itself.
> In the end, they control every protocol, become the gatekeepers for the web.
I feel like I either misunderstand pass keys or live in some twilight zone where they're ok even though I cannot wrote them down or memorize them, I can only have invisible magic stuck on my phone.
If I show up naked, I can login to the system via password but I am conpletely useless with a pass key. And for somebody like myself who uses multiple devices daily (two phones, two tablets, several laptops and desktops), it seems a nightmare to set them all up or maintain:-(
It feels a system designed for those who live by their phone and trust some specific service provider with their life. I'm not in either of those categories :-(. I still don't understand what the "Keepass, "little black notebook", and "good memory" equivalents are.
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.
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…
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.
> Passkeys are essentially site-specific cryptographic keypairs, which are fine, combined with big tech company paternalism, which is intolerable.
Deleted Comment
Standards are slow and expensive to create and evolve. They involve endless meetings, discussion and design. However, the outcome is freedom.
The idea that this should have been “extremely simple” is just standard hubris.
> However, the outcome is freedom.
This is an exceptionally naive take.
> The idea that this should have been “extremely simple” is just standard hubris.
Why? Export-import of passwords is extremely simple and can be done with copy-paste or CSV. The only thing preventing this with passkeys is the paternalistic idea that users of passkeys should not be allowed to access them directly.
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?
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.
(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)
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.
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.
The remaining issue is moving the credentials between providers, which is an annoying limitation. But you can always add a different passkey to the site using the provider you want, so although annoying it is not the end of the world…
The original limitation is similar to the usability of actual physical security keys, which (depending on the setup mode) are deliberately designed such that the private key material is not recoverable. Software based keys don’t HAVE to share the same limitation, but it seems more like a missing feature than attributing malice to the creators of the spec.
Why should we even need a third-party provider? Imagine needing a third-party "provider" for your own ssh keys.
Deleted Comment
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.
Do they? Is that legally mandated somewhere, or can they just say "You're stuffed, make a new account if you want"?
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.
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.
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.
Deleted Comment
You kind of have to go out of your way to not have your keys backed up. By default, the easiest route is using your android or iphone and both of them back the keys up using icloud Keychain or google password manager. 1Password, bitwarden, all support syncing. Chrome will allow saving it to icloud or your google account. Keepass can be manually synced. Windows is adding sync in the next update for windows hello. List goes on.
The other thing is that multiple keys can be created. Easiest way to see this in action is google's account security settings. Log in (if you have an account), hit create passkey, see your options and play around with them. You'll also see you can add a hardware security key too, which isn't nothing new but if you have one that's another key that doesn't rely on a mobile device!
If all else fails, the usual account recovery process applies. Much like it would if you forgot your password.
And if my google account gets banned, I lose access to a trillion things instead of just one.
I was hoping passkeys would work on 1password,but chrome/brave don't support that yet.
It seems like a passkey is just a password though
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.
It can also be used as an second factor for traditional username/password auth (with or without user verification).
Losing a passkey is no different to losing any other credential: you need another method to authenticate or recover your account.
It’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.
Deleted Comment
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.
I have recovery mechanisms for regaining access if I lose all my keys, but (while I'll admit that the tooling for managing public keys in the general case is lacking) you're not supposed to (need to) copy private keys between devices.
Technically you can generate a GPG key and load that onto multiple Yubikeys, but that's not as secure as letting the Yubikey itself generate the key. Plus if you only use one GPG key and one of the Yubikeys is lost (but not destroyed) then you have to rewrite all the remaining Yubikeys with a new GPG key since you can't selectively revoke them.
The qualifier “mainstream” is quite silly here. Bitwarden and KeePassXC work great, can be backed up, and meet your needs. Why must “mainstream” providers support power user features?
In-practice, 1Password, iCloud Keychain, etc are backed up because they work across devices and those systems already have recovery mechanisms in place if you lose your devices. They’re synchronized credentials available everywhere.
The only way to make a problem is to “store a passkey locally”. Then you’re out of luck. If you just use Bitwarden or KeePassXC, this is a non-issue.
> It could be so simple, just look at SSH keys, which I think largely use the same principle.
Passkeys are technically complex in implementation because they’re trying to be better than passwords for the lowest common denominator of users. If you spend time looking at how they work and interact with sites, the solution is relatively simple and easily understood. Maybe they’re just unfamiliar to you? I personally have never explained to a layperson how SSH keys work without first explaining PKI, which is a pretty big ask for my mom.
On the other hand I like the security benefit of hardware passkeys. But these are unusable because 1) most sites that support passkeys don’t support registration of more than one passkey, and it’s hard to determine if they do or not, and 2) the security benefit is defeated if sites allow recovery without a registered passkey, which most do, and again it’s hard to figure out if they do or not.
So what’s the point?
Lots of complaints about passkeys and "big tech paternalism" in the comments here, and frankly I don't think ya'll deal with the middle of the bell curve user base that much.
I've got users who, by literally no fault of their own, are being social engineered into reading back their SMS OTP codes to fake tech support. State of the art in industry is basically trying to understand every action that is happening on a device (via mobile phone network providers, location, their actions across multiple other sites, etc. etc. through vendors providing this type of intelligence... by vacuuming up all your data) to understand if fraud is happening by seeing if you can even trust the device that is getting the SMS. Every time we make a step forward in privacy, this gets harder and harder (fingerprinting devices is basically pointless now, so how do I tell if this should be a trusted device or not) so there is a driving force against improving user privacy coming from these vendors.
Passkeys are the first positive step in auth I've seen in a decade that the average user will pickup and use, it helps them login and helps them not try to set a weak password they shared with multiple sites, and they can't read it back to a scammer who is fake tech support.
Would I like passkeys to be more like ssh keys? um, maybe but I don't care about it one bit in practice. I use passkeys for everything I can and I've never once seen friction. The average user does not want to deal with backing up their passkeys or even thinking about them, heck most of them don't. If anyone in the comments doesn't like the implementation of webauthn, suggest changes to the spec and do the work to get it implemented instead of complaining about it in the comments.
Simple: clients meant for consumers SHALL NOT provide any attestation information. Those fields are intended to be used only by managed devices.
People can be free to use a device that has guard rails for them. The issue is when e.g. my bank forces me to prove I am using a malware device, which is pretty much everything from "big tech". Normies will stay on the normal path anyway and will be using one of those devices, so there shouldn't be a need to block the people who are using something weird, because by definition they are not the average user.
High(er) security environments exist, and some extremely anti-user features make tons of sense there - anti-user is kinda the point, you don't want people to do anything they like. But those environments should not be allowed to impact any other environments, it's just going to foster abuse. MDM divides them very cleanly.
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.
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.
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.
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.
Can you elaborate? I'm curious. Is there a storage problem?
That’s great for you, but they don’t currently work like that for anyone
- using anything other than Chrome or Safari (many sites perform broken user agent based support detection)
- using both iOS and Android (at least not without setting up a third-party password manager, which not everybody knows how to do, or even why)
- not using iCloud (iOS just outright refuses to store local-only credentials, last time I checked at least)
Passkeys are absolutely an improvement for anyone able to use them, but that’s still strictly less users that can use passwords. And even for those that can use them, the availability story is still worse (almost by design, but that’s no consolation for a locked-out user).
> If anyone in the comments doesn't like the implementation of webauthn, suggest changes to the spec and do the work to get it implemented instead of complaining about it in the comments.
I have, with no success. There seems to be a misalignment of priorities and incentives. I even understand where the editors are coming from, but like most industry-sponsored specs, it’s really not the democracy you’re trying to paint it as.
You’re 100% right that the experience isn’t seamless yet for people outside of apple’s ecosystem or google’s but this is just catching hold, and the spec isn’t complete, this original article demonstrates a real improvement that should fix a pain point.
So, I do appreciate the way you’re engaging on each point, but I don’t understand what changes _you_ would like to see.
>Using anything other than chrome or safari These will improve as support improves, I see failures and then have to deal with support calls when the user is on something that isn’t supported well. I don’t check user agent, but it would cut down on my support costs.
>using iOS and Android without a 3rd party password manager
Ok, I understand the problem here, and I think I understand the issue with passkeys not being savable like a ssh key, because the apple and android ecosystem is using its keychain and syncing that keychain with its respective cloud service, you can’t use the same passkey on both systems… but the restriction here saves the users from losing these digital keys or having them stolen, and saves me as someone trying to protect their money from basically having to make a passkey need enough secondary data about your device and other factors. I think you’re missing what I posted about for 2 factor… to support it right now for anything other hardware keys (which are basically only supported in volume by a different central authority, like the IT dept)
I need a huge data vacuum operation on the backend to know who you are, where you are, what device you’re using, what that device has been doing recently, if you’ve swapped your sim, etc etc etc. as a counter, you can just make a passkey on the iOS and the android ecosystem, and now you’re good. Extend this to any other ecosystem you want. Yubico has an author on the spec, they aren’t ignoring the use of hardware keys. I’m sure you would be happy to not participate in that data vacuuming operation, and while it’s dual use (marketing and fraud prevention) they still have a veneer of use for the consumer.
Perfect is the enemy of good in this case. Let’s help all these regular people not get scammed
Deleted Comment