A few weeks ago I had a bug with bitwarden where every passkey wanted to load from the macbook instead of bitwarden. I ended up being locked out of a few accounts that didn't have OTPs as a fallback. Mostly inconsequential stuff like Twitter.
I love passkeys, but they're still kinda hard to use. There's several sites that wont let you enroll multiple ones and it's easy for systems to step on each other like the aforementioned experience.
The problem is fallback. All my banking apps have SMS OTP fallbacks and that's no better than having only SMS OTP. If you're building these systems make sure you have good fallbacks. What matters in design is not so much how well it works when things go right but how well it works when things go wrong. With security you really cannot ignore edge cases
I don't think this is a security vs usability thing. A lot of UIs are intentionally confusing.
Apple wants you to use iCloud passkeys, Microsoft wants you to use Microsoft Account passkeys, Google wants you to use Google passkeys. Even if you have a dedicated USB device plugged in, browsers keep defaulting to the cloud accounts.
Bitwarden's approach is to simply hijack the passkey request before the browser can respond and throw itself front and center. It's a terrible hack but it works on every browser at the very least.
If these companies cared about their users more than they cared about throwing up walled gardens, they wouldn't put a USB key behind "Choose another method" -> "Dedicated device" -> "Security key" -> "Confirm" while offering one-click login with their cloud account. And they would offer a proper API for third party applications to integrate into the native passkey storage.
That's one way to read but I think a narrow way. Besides, my issue wasn't actually an issue with security now was it?
In practice we don't actually want the best security though. We frequently make concessions. I mean with my bank I don't want "the best" security. If I lose my credentials I don't want to go broke. If my credentials get hacked (especially if hacked by no fault of my own!) I want that money recovered. These things would not be possible with "the best" security.
In fact, in a different interpretation I would call those paths less secure. Ability to recover is a security feature just as much as it's not.
Both security and privacy do not have unique all encompassing solutions. They are dependent upon the threat model.
Importantly when designing things you have to understand modes of failure. When you design a bridge you design it to fail in certain ways because when/if it fails you want it to do so in the safest possible way. Why does this pattern of thinking not also apply here? It seems just as critical here! In physical security you also have to design things for both fail open and fail closed. You don't want you always fail close, doing so gets people killed! So why is the thinking different in software?
Not to mention:
How do I login from my Linux machine if I'm only using my iCloud key?
Your logic would lock me into the apple ecosystem forever and that's a worse security setting than anything else we discussed. Apple decides to become evil and I'm just fucked. Or swap Apple with Microsoft who is actively demonstrating that transition
Some of the things that came out before passkeys were harder and not more secure, like OTP. Especially the way that earlier versions of Google Authenticator implemented it. We're finally close to a permanent "remember me" button that most people wanted, but it needs a bit more polishing.
If I'm being honest, I regret every passkey I ever made. With my old flow, I knew when to use my Yubikey, when to use my OTP, and when to use SMS 2FA. With the new flow, these things say "use your passkey" and I don't know where in god's name I did this. If I did this on my iPhone in a WebUI that popped up when I followed a link to buy something, then it's never going to be on Chrome or Bitwarden.
I've decided to stop adding new ones. I'll just OTP 2FA. It's simple, reliable, and I can keep it in Bitwarden safely.
It's all a bit of a mess right now, but with some fiddling in settings you should be able to get your passkeys in one place (probably Bitwarden) and access them everywhere.
Safari on iOS can store and use passkeys from any app that implements the right system API, including the default Apple Passwords but also Bitwarden and Chrome.
For desktop, you can either use a browser extension provided by some password managers (such as Bitwarden), or if you're on a Mac, Safari and Chrome can access passkeys from other apps similarly to on iOS (but not as many providers support this API on Mac as on iOS, and in particular Bitwarden doesn't, so you'd have to use the extension for that).
I can't blame you. I know the passkey UX on Windows was absolutely horrible (and probably still is). However I can't say that I relate. I use 1Password and I don't think I've literally ever been asked to use the native UI. It always goes straight to 1Password. I'm not sure why we have different experiences. (I use a mac, an iphone, and a google pixel)
1Password has then implemented things better. I have a Mac, an iPhone, and a Linux desktop. I don’t know why I’m in this state. PEBKAC is entirely possible but OTP 2FA is foolproof for this fool.
The scariest thing is the casual mention of the Digital Credentials API[1]. Forget passkeys, when you need government issued credentials to surf the net, the good times are over.
There are plenty of websites and services already where you need to prove your identity to use them. The digital credentials API is an attempt to standardise that which is already legally required in the US, the UK, Australia, and the EU, except without having to upload a picture of your ID to a shady third party website.
I've never had to upload my government ID to any site; and none of my family have either. It's beyond naive to think that enshrining such a protocol won't lead to more widespread adoption, and even legislation requiring it. It's infrastructure that is quietly being built first, and enthusiastic authoritarian governments will eagerly embrace it.
Have you read their document? They require Google Wallet with the Google Play Services to prove your id on your desktop computer, it's absolute insanity. No thanks.
I've never seen a legitimate use case where I need to prove my identity to use a website anyways.
The UK law is age verification not identity verification. Now, everyone in practice has collapsed that distinction, whether from incompetence or malice..
It's likely that the websites need your actual government issued credentials are not your twitters and your hacker news, but government websites that actually need to link the web user to the citizen. As an example my country has a portal that you use as a citizen to book appointments to government institutions, keeps you updated about the status of your requests, allows you to securely upload scans for additional documents that your request might need, etc.
One thing I ran into recently when I played around with passkeys is the problem of orphaned keys. Basically if I log into a website using the passkey and then go to my account settings and remove that passkey then log out I have a problem. Now I can’t sign in but when I go to recover my account iOS/macOS will refuse to create a new passkey because one already exists for this website. So I have to go to my passwords list and manually remove it. I believe I was correctly using the JS API for signaling orphaned keys but the OS still wouldn’t remove it so it was a situation of having to educate the user to remove the orphaned key manually (and hoping the user doesn’t get confused and remove the wrong key). You also apparently can’t create more than one passkey for the same username and the same website. So if I initially create an account from my MacBook and the passkey gets listed as “MacBook”, I then go to log in from my iPhone and it still uses the “MacBook” passkey because of iCloud sync. But this is confusing because I cannot have an iPhone key.
Overall it’s not terrible but I think these edge cases are going to keep biting people and need to be addressed in some way. And yes I understand that I could use a Yubikey or Bitwarden or some such but the point was that I wanted to see how this flow works for “normal” users who just use the iCloud Keychain and the experience leaves something to be desired.
> So if I initially create an account from my MacBook and the passkey gets listed as “MacBook”, I then go to log in from my iPhone and it still uses the “MacBook” passkey because of iCloud sync. But this is confusing because I cannot have an iPhone key.
Now try using a Windows or Linux computer...
This is why I strongly prefer to not use OSX passkeys. How the fuck am I supposed to login on my nix machines if you only allow me to enroll one passkey?!
You register from your MacBook, then add your Android phone, then remove your MacBook key, the lose your Android phone.
The messed up thing is that the simplest backup option is a magic login link which is obviously less secure. Also you cannot sink a passkey between platforms unless you use a third party Authenticator so you have to have a backup method of some sort even if not for recovery reasons.
Love these "lessons learned" posts, keep the coming!
My only feedback is about the Quickstart of passkeybot, "feed this example into a good LLM with these instructions". I undeerstand the idea, but I was a bit shocked that the first time I see these sort of instructions is for an auth framework.
I am in the middle of writing a passkey-driven server dashboard app (native SwiftUI app, with a small server component).
In the future, I would like to use passkeys as much as possible, but they do present a bit more friction to users than Sign in with Apple. When I was initially learning them I wrote this up: https://littlegreenviper.com/series/passkeys/
The passkey spec authors think websites should be able to ban clients which allow users to manage their own data[1,2]. It makes me really hesitant to adopt passkeys if my client could get banned because it's open source and lets me control my client how I want to. It appears to be more useful for vendor lock-in than anything else[3]. A shame, since it could've been a cool tech if they had built it to be resilient to this kind of abuse, but it's clear they think vendor lock-in is actually a core feature of the protocol.
The point of passkeys is that they're unexportable. Software implementations like Bitwarden/KeepassXC/etc. making them exportable go right against the point of the protocols.
I personally think the ability to export+import passkeys is a good thing from a backup point of view, but he's not wrong in suggesting that companies actually using the high security features of passkeys will eventually block software implementations like these.
This isn't about vendor lock-in. Nobody is asking for KeepassXC to remove passkey support. This is about security software implementing an API and not fulfilling the expectations that come with such an implementation. To quote the comment you linked:
> That's fine. Let determined people do that, but don't make it easy for a user to be tricked into handing over all of their credentials in clear text.
It's fine for them to make suggestions for projects to improve their software. The problem is threatening clients with being banned because they don't agree with those suggestions. If a website is able to ban me because of the passkey client I'm using, then I'm just not going to use passkeys. It's too unreliable.
> personally think the ability to export+import passkeys is a good thing from a backup point of view
It's not a "good thing," it's absolutely critical. If I can't back up my credentials in a location that I trust, then it's not an acceptable login method. What happens if my PC goes down and I couldn't export my data? I just can't log in anywhere? KeePassXC lets me do that, but the spec authors think it's appropriate to ban me for using it because it lets me manage my own data. That's bonkers.
But the natural result is vendor lock in. To stop exports of keys, sites will need a whitelist and secure method to verify the hardware or software implementation has not been tampered with. If an implementation is banned, the obvious solution is to allow it to pretend to be a non-banned implementation. Or admin level processes smuggling keys out of approved implementations. I don't think anyone wants an arms race, thus the vague threats to remove features that users are demanding before they will consider buying into the ecosystem.
I agree with you but the whole thing makes me uncomfortable. We're definitely making it easier for these security conscious companies to do vendor lock in if we encourage passkey use.
At this time I'm not really sure if anyone can really say there's a 'point' to passkeys anymore. They just are exportable now, both Google's and Apple's implementation are synced instead of device-bound putting them at the level of Bitwarden / KeepassXC. Backups and multi-device have become a critical feature for users which breaks attestation so it's really just those weirdos with Yubikeys.
I think we're verrry slowly inching toward shedding all the security nerd self-indulgences and getting to what I think is the eventual endgame which PassKeys are just keys and ultimately a fairly user friendly way of getting people to use a password manager without it feeling like one. All the other features seem like noise.
>The point of passkeys is that they're unexportable. Software implementations like Bitwarden/KeepassXC/etc. making them exportable go right against the point of the protocols.
No, that is absolutely not the point. The points of using pub/priv keys for asymmetric auth instead of passwords (symmetric, manually generated auth) are:
- Server-side (ie, central point) hacks no longer matter an iota from a user auth pov. No more having to worry about reuse anywhere else, about going around changing passwords, nada, because the server simply doesn't have anything that can be used for auth anymore at all. No more concerns about whether they're storing it with the right hash functions or whatever, they could publish all the public keys in plain text and it'd be irrelevant. This fantastically changes the economics of attacks, since now instead of hacking one place and getting thousands/millions/hundreds of millions of credentials you'd have to hack every single separate client.
- As a practical matter, the process means eliminating the whole ancient hodgepodge of password requirements (often outright anti-security) and bad practices and manual generation work. Everything gets standardized on something that will always be random, unique, and secure.
And that should be it. That's the point and the value, always was. The only goal should be to put a nice UX and universal standard around. But of course, modern enshittified tech being enshittified, they had to shove in a bunch of stupid fucking bullshit garbage like what you're talking about.
So if a client ever goes rogue someday (either intentionally or has been compromised) and starts shipping off private material to a malicious third party, you think relying parties shouldn’t have the option not to trust that client anymore?
Sure that's bad, but the trouble is you're not thinking about what the alternative is. If users don't have control over their own data, then someone else does.
As stated by the spec authors on KeePassXC's bug tracker, open source software may be modified by the user, so cannot be trusted. The passkey proposal is for all of your keys to be managed by proprietary software validated by your phone or your computer's TPM module. That means one of three big, US-based tech companies will control all of the world's login data. Those 3 companies are all currently involved in the largest fascist-taint-tongue-polishing in US history, and we want to hand them control over the world's logins. That's a much, much bigger risk than some users doing something stupid.
The spec needs to be written with the assumption that the user's private keystore may be hostile to the user's own interests, because in the real world, it is. It needs to be written to mitigate damage to the user from a hostile keystore. Instead, the spec places total trust in the keystore. This is a fatal error.
Per the article, Apple does do attestation. By default attestation is off unless you have enterprise management turned on.
But the existence of attestation means Apple could at any time in the future make attestation on by default and suddenly our devices control our secrets more than we do.
> generateKey is a JS API that allows you to create new key pairs, where the private key cannot be extracted similar to passkeys.
Is that "cannot be extracted" from JS only, or is this an actual device-locked, TPM/SEP-bound key like passkeys?
If it is, it seems kind of like the buried lede to me that there is a browser API that lets any website built its own completely unstandardized quasi-passkey system and lock the key to the current device.
Yes, where practical. Though recognize that by their very nature web apps aren't part of the trust network. The browser and security stack can make a key for them to use, but it's not possible to be sure that the user of that key is not subject to attack at the backend (or even front end, really the best you can do there is XSS protection, which is hardly at the standard of "crytographically secure").
And likewise you as the app vendor can know the key was generated, and that it works, but you can't[1] know that it's actually locked to a device or that it's non-exportable. You could be running in a virtualized environment that logged everything.
Basically it's not really that useful. Which is sort of true for security hardware in general. It's great for the stuff the device vendors have wired up (which amounts to "secured boot", "identifying specific known devices" and "validating human user biometrics on a secured device"), but not really extensible in the way you'd want it to be.
[1] Within the bounds of this particular API, anyway. There may be some form of vendor signing you can use to e.g. verify that it was done on iOS or ChromeOS or some other fully-secured platform. I honestly don't know.
Readit News
I love passkeys, but they're still kinda hard to use. There's several sites that wont let you enroll multiple ones and it's easy for systems to step on each other like the aforementioned experience.
The problem is fallback. All my banking apps have SMS OTP fallbacks and that's no better than having only SMS OTP. If you're building these systems make sure you have good fallbacks. What matters in design is not so much how well it works when things go right but how well it works when things go wrong. With security you really cannot ignore edge cases
The easier it is to do things, like use another channel, the harder it is to keep secure.
The easier it is to keep secure, the harder it is to use.
Apple wants you to use iCloud passkeys, Microsoft wants you to use Microsoft Account passkeys, Google wants you to use Google passkeys. Even if you have a dedicated USB device plugged in, browsers keep defaulting to the cloud accounts.
Bitwarden's approach is to simply hijack the passkey request before the browser can respond and throw itself front and center. It's a terrible hack but it works on every browser at the very least.
If these companies cared about their users more than they cared about throwing up walled gardens, they wouldn't put a USB key behind "Choose another method" -> "Dedicated device" -> "Security key" -> "Confirm" while offering one-click login with their cloud account. And they would offer a proper API for third party applications to integrate into the native passkey storage.
In practice we don't actually want the best security though. We frequently make concessions. I mean with my bank I don't want "the best" security. If I lose my credentials I don't want to go broke. If my credentials get hacked (especially if hacked by no fault of my own!) I want that money recovered. These things would not be possible with "the best" security.
In fact, in a different interpretation I would call those paths less secure. Ability to recover is a security feature just as much as it's not.
Both security and privacy do not have unique all encompassing solutions. They are dependent upon the threat model.
Importantly when designing things you have to understand modes of failure. When you design a bridge you design it to fail in certain ways because when/if it fails you want it to do so in the safest possible way. Why does this pattern of thinking not also apply here? It seems just as critical here! In physical security you also have to design things for both fail open and fail closed. You don't want you always fail close, doing so gets people killed! So why is the thinking different in software?
Not to mention:
How do I login from my Linux machine if I'm only using my iCloud key?
Your logic would lock me into the apple ecosystem forever and that's a worse security setting than anything else we discussed. Apple decides to become evil and I'm just fucked. Or swap Apple with Microsoft who is actively demonstrating that transition
In terms of security, yes. But not in terms of convenience.
I've decided to stop adding new ones. I'll just OTP 2FA. It's simple, reliable, and I can keep it in Bitwarden safely.
Safari on iOS can store and use passkeys from any app that implements the right system API, including the default Apple Passwords but also Bitwarden and Chrome.
For desktop, you can either use a browser extension provided by some password managers (such as Bitwarden), or if you're on a Mac, Safari and Chrome can access passkeys from other apps similarly to on iOS (but not as many providers support this API on Mac as on iOS, and in particular Bitwarden doesn't, so you'd have to use the extension for that).
[1] https://developer.chrome.com/blog/digital-credentials-api-sh...
I've never seen a legitimate use case where I need to prove my identity to use a website anyways.
Overall it’s not terrible but I think these edge cases are going to keep biting people and need to be addressed in some way. And yes I understand that I could use a Yubikey or Bitwarden or some such but the point was that I wanted to see how this flow works for “normal” users who just use the iCloud Keychain and the experience leaves something to be desired.
This is why I strongly prefer to not use OSX passkeys. How the fuck am I supposed to login on my nix machines if you only allow me to enroll one passkey?!
The messed up thing is that the simplest backup option is a magic login link which is obviously less secure. Also you cannot sink a passkey between platforms unless you use a third party Authenticator so you have to have a backup method of some sort even if not for recovery reasons.
My only feedback is about the Quickstart of passkeybot, "feed this example into a good LLM with these instructions". I undeerstand the idea, but I was a bit shocked that the first time I see these sort of instructions is for an auth framework.
I am in the middle of writing a passkey-driven server dashboard app (native SwiftUI app, with a small server component).
In the future, I would like to use passkeys as much as possible, but they do present a bit more friction to users than Sign in with Apple. When I was initially learning them I wrote this up: https://littlegreenviper.com/series/passkeys/
[1] Spec author quote: "To be very honest here, you risk having KeePassXC blocked by relying parties." https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
[2] https://www.smokingonabike.com/2025/01/04/passkey-marketing-...
[3] https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shatt...
I personally think the ability to export+import passkeys is a good thing from a backup point of view, but he's not wrong in suggesting that companies actually using the high security features of passkeys will eventually block software implementations like these.
This isn't about vendor lock-in. Nobody is asking for KeepassXC to remove passkey support. This is about security software implementing an API and not fulfilling the expectations that come with such an implementation. To quote the comment you linked:
> That's fine. Let determined people do that, but don't make it easy for a user to be tricked into handing over all of their credentials in clear text.
> personally think the ability to export+import passkeys is a good thing from a backup point of view
It's not a "good thing," it's absolutely critical. If I can't back up my credentials in a location that I trust, then it's not an acceptable login method. What happens if my PC goes down and I couldn't export my data? I just can't log in anywhere? KeePassXC lets me do that, but the spec authors think it's appropriate to ban me for using it because it lets me manage my own data. That's bonkers.
1) that they're enforcing these specs for technical reasons, not because they want vendor lock-in
2) a result of these decisions in the long term is vendor lock-in
I think we're verrry slowly inching toward shedding all the security nerd self-indulgences and getting to what I think is the eventual endgame which PassKeys are just keys and ultimately a fairly user friendly way of getting people to use a password manager without it feeling like one. All the other features seem like noise.
No, that is absolutely not the point. The points of using pub/priv keys for asymmetric auth instead of passwords (symmetric, manually generated auth) are:
- Server-side (ie, central point) hacks no longer matter an iota from a user auth pov. No more having to worry about reuse anywhere else, about going around changing passwords, nada, because the server simply doesn't have anything that can be used for auth anymore at all. No more concerns about whether they're storing it with the right hash functions or whatever, they could publish all the public keys in plain text and it'd be irrelevant. This fantastically changes the economics of attacks, since now instead of hacking one place and getting thousands/millions/hundreds of millions of credentials you'd have to hack every single separate client.
- As a practical matter, the process means eliminating the whole ancient hodgepodge of password requirements (often outright anti-security) and bad practices and manual generation work. Everything gets standardized on something that will always be random, unique, and secure.
And that should be it. That's the point and the value, always was. The only goal should be to put a nice UX and universal standard around. But of course, modern enshittified tech being enshittified, they had to shove in a bunch of stupid fucking bullshit garbage like what you're talking about.
As stated by the spec authors on KeePassXC's bug tracker, open source software may be modified by the user, so cannot be trusted. The passkey proposal is for all of your keys to be managed by proprietary software validated by your phone or your computer's TPM module. That means one of three big, US-based tech companies will control all of the world's login data. Those 3 companies are all currently involved in the largest fascist-taint-tongue-polishing in US history, and we want to hand them control over the world's logins. That's a much, much bigger risk than some users doing something stupid.
The spec needs to be written with the assumption that the user's private keystore may be hostile to the user's own interests, because in the real world, it is. It needs to be written to mitigate damage to the user from a hostile keystore. Instead, the spec places total trust in the keystore. This is a fatal error.
But the existence of attestation means Apple could at any time in the future make attestation on by default and suddenly our devices control our secrets more than we do.
Is that "cannot be extracted" from JS only, or is this an actual device-locked, TPM/SEP-bound key like passkeys?
If it is, it seems kind of like the buried lede to me that there is a browser API that lets any website built its own completely unstandardized quasi-passkey system and lock the key to the current device.
And likewise you as the app vendor can know the key was generated, and that it works, but you can't[1] know that it's actually locked to a device or that it's non-exportable. You could be running in a virtualized environment that logged everything.
Basically it's not really that useful. Which is sort of true for security hardware in general. It's great for the stuff the device vendors have wired up (which amounts to "secured boot", "identifying specific known devices" and "validating human user biometrics on a secured device"), but not really extensible in the way you'd want it to be.
[1] Within the bounds of this particular API, anyway. There may be some form of vendor signing you can use to e.g. verify that it was done on iOS or ChromeOS or some other fully-secured platform. I honestly don't know.
the capability is there, but it would he massively inconvenient, since it requires a lot of lockdown
might be the next generation of anti-cheats though
Deleted Comment