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.
Yeah, the passkey provider management is absolutely horrendous and is the biggest blocker to passkey adoption in my eyes. I have 3 different sources (iCloud keychain, Yubikey, and Enpass) and in the best case it's some extra clicks like you mention, in the worst case it just simply won't let me select the correct provider.
I've resigned to registering a passkey into all of my providers and just letting the most platform native option win for now.
I remember once I was working for a big tech and we had windows computers. I tried to use Hello so I could login with my fingerprint. It broke outlook for some reason. So I switched to a Yubi key since they were offering.
Every login was the same: fails -> try again or try different method -> list of methods (including "security key") -> ok -> tap security key -> ok
It would not let me set the key as the default and there were two unnecessary clicks. The box literally only had a single button (besides the standard x on the window)! It was absolutely infuriating.
I'm with you. I don't believe these companies are actually trying to create the best solutions. And you can absolutely see that when you try to move from one ecosystem to another.
Look at my problem again and now consider had I been using my iCloud key and wanted to login from my Linux machine. It literally wouldn't be possible!
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.
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.
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.
The UK law is age verification not identity verification. Now, everyone in practice has collapsed that distinction, whether from incompetence or malice..
Age verification inevitably turns into identity verification. And this is by design.
Age verification obviously is the excuse to implement identity verification.
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.
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.
From my perspective we can talk about that when it actually happens. No need to slide on that slippery slope just yet, or at least, not in my neighbourhood...
Or corpos decide the time is ripe to force users to do it, so they can better optimize their surveillance targeting. Google has been nagging me with a periodic Android popup for like a decade to "add my birthday to help them comply with the law". Eventually that tack of borderline misleading will turn into an outright demand.
No? A few percent of people dissenting doesn't move the needle for the company analysts, all the "competitors" tend to move in lock step since their managements are all tuned into the same memestream, and using such systems has steadily become more de facto mandatory for many previously-unrelated tasks.
I don't know what you mean? My first point was just about how our individual behavior is not going to affect companies' decisions. The subsequent points were about how it's becoming increasingly harder to avoid supporting any scummy companies.
And the more this behavior is normalized, the easier it is for governments to make it illegal for any site to not demand users' government-registered identities.
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.
I don't see where he is threatening anybody? He's just stating the obvious. If you promise to store a key in a non-exportable format and then create a big export button, websites won't trust your software.
> What happens if my PC goes down and I couldn't export my data? I just can't log in anywhere?
Then you follow the procedure you would follow for when you'd forget your password. Probably a password reset through email, maybe calling customer support. Or if you have it set up, you could use the passkey set up on your phone or Yubikey or whatever to log in and create a new password on your new PC.
Passkeys aren't passwords, that's the whole point. It's modelled after the "something you have" factor, not "something you know". If you're finding workarounds to violate the security design, you're not gaining any advantage by using passkeys. Just use a password if you want to use a password.
> If you're finding workarounds to violate the security design, you're not gaining any advantage by using passkeys.
The trouble is, if websites are allowed/encouraged to ban clients, then the advantages you're talking about come with the downside of hard-tying yourself to one of 3 US-based Big Tech companies, because those will be the only ones who will ship clients declared "secure." That's not a trade-off I'm willing to make for something as critical as my service logins. You can already see this happening, almost every article talking about passkeys assumes you're logging in with an Apple, Google, or Microsoft device.
> Then you follow the procedure you would follow for when you'd forget your password. Probably a password reset through email, maybe calling customer support.
This is a downgrade from passwords (and exportable passkeys), where I can just restore it from a backup.
> Just use a password if you want to use a password.
Yeah, that's what I plan to keep doing, unfortunately. What I'm worried about is a password-less future where that's no longer an option and we all have to submit to using one of Android, iOS, or Windows to log in to everything because those are the only clients that can be trusted(TM) to handle the user's data as the big tech companies and governments desire it to be handled. This is a dark future.
You already need to submit to iOS or stock Android for a myriad of banking or government apps that use remote attestation to verify that you are running "untampered" software.
FWIW this has not been my experience in the US, I've always been able to use websites for these things. I use my phone for almost nothing important since I don't trust it. But yes, I fear we are heading in that direction too.
I keep seeing this where? What banks don’t allow you to go to their website and use them from your phone? Which government apps don’t also have websites?
Not in the western countries yet, I guess. I live in Thailand and have accounts in two banks and both of them only allow usage through an app that's only available through the App/Play store. Android version of Krungthai's bank app freaks out if you have developer settings enabled (even without changing anything, just enabling the access is enough to lock you out). And to use that app in the first place, you have to go to a branch and have staff set the app for, as passing the facial scan checks is impossible for foreigners.
Several German banks (at least mine, one of the bigger ones) exclusively have you use an app for 2FA, you can still log via the website if you are lucky (as long as you have that one saved) but not do any transactions. So I would call that required.
The threat he relayed was more serious than the threat he made. But it is a threat when a person with influence suggests they may support a punishment.
> If you promise to store a key in a non-exportable format
There was no such promise. The people who wish Passkeys to replace passwords did not demand it yet even.
That's what I still don't understand. Why is "something you have" deemed more secure than "something you know". For a while everyone was harping on MFA, but suddenly passkeys came along and now SFA is fine as long as it's a passkey?
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 this, but I think the spec author's public statements means we don't need to give them the benefit of the doubt. People have repeatedly pointed out how this will result in vendor lock-in, and their response is either "yep, working as intended" or "we don't want to talk about this anymore." They're just steamrolling ahead with support from all the Big Tech companies. It's a really ugly situation =/
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.
>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.
Thank you, you have been the first person to articulate why passkeys are actually an advantage. Everyone else I've read from was focusing on the client side and there I really don't see a significant advantage. In fact it seems it's a downgrade from MFA, so I never understood the push for passkeys.
This is very well put, thank you (though I think you got a little needlessly aggro at the end :) ). A big part of why I find this situation so frustrating is passkeys are such a cool technology and genuinely a big improvement over passwords. I even spent a whole day writing a big article about how cool they are! But the big tech company lock-in stuff is so obvious, and so strongly supported by the spec authors and the passkey community, that it's hard to see it as unintentional. It completely poisons the technology, and that sucks because I really do want to use it.
>This is very well put, thank you (though I think you got a little needlessly aggro at the end :) ).
My apologies to GP if it came across as too personally aggro, I did mention the corps and their walled gardens to try to be clear on the focus, but the situation does really make me absolutely furious and also truly sad. This should have been such a simple, universal win/win/win that made everything better for everyone. But as you say:
>and so strongly supported by the spec authors and the passkey community, that it's hard to see it as unintentional. It completely poisons the technology, and that sucks because I really do want to use it.
Yeah, 110%. I'm one of the very few who actually tried to use certificates for web authentication back in the 00s, and it did work pretty darn well surprisingly! There were even a few commercial web services that tried it out like the now defunct StartSSL. It was just the whole flow around it was too clunky for regular people and needed some additional standardization and polish. If only the right catalyst had happened to make it a priority in the 2000s it might well have been done in a lasting good way that'd then be too sticky and entrenched to fuck with now. It's depressing to see it being hijacked and poisoned like it has been :(.
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.
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.
By all means, make a proposal to the FIDO Alliance that solves all these problems without introducing new ones. You're going to have to anticipate all the objections and be prepared to answer them, though.
I'm not the one trying to push a new standard, but sure, I'll do it for them. Explicitly allow users to export and back up their private keys in a documented file format, make client banning hard/discouraged, and no longer maintain a naughty client list. That's it.
It would, yes. Thus it’s an action I would only recommend if doing so would help prevent serious injury to their customers. If it comes down to a choice between locking a customer out and having, say, their money stolen, then the scale tips towards safety.
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.
No, Apple can't suddenly start doing attestation in the future by default because that would instantly kill all the passkeys that have already been created on Apple devices without attestation. It would be as if a home security company went around and changed all the locks they had installed on their customers' front doors. It would be instant suicide as a trusted vendor.
> 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.
Apple is already shipping remote attestation in Safari in the form of Private Access Tokens (https://developer.apple.com/news/?id=huqjyh7k), though Cloudflare's trial for that has ended. Safari authenticates and attests itself against Apple, who hands out tokens to your browser, which in turn get used to bypass CAPTCHAs and other anti spam filters.
There's no direct remote attestation implementation for passkeys yet, but remote attestation for web browsers has been around for a few years now.
Ask anyone who has tried to run banking apps on GrapheneOS how that works out in practice.
GrapheneOS supports attestation. GrapheneOS even provides the sort of security guarantees that would make risk management types at banks happy, but it isn't popular enough for them to be motivated to support it as an attestation target.
Now imagine it was practical for websites to require attestation from browsers. How likely do you think it that all the major services would accept anything other than Chrome, Safari, and Edge?
In oauth2: when I /1 associate a random uuidv4 for each new flow with my user (server side), /2 stick that uuid into the state parameter, and then /3 look up my user with this on callback-endpoint execution. Isn't PKCE in that case redundant?
PKCE protects the auth token from interception by making it so that only your code that started the flow can redeem it by proving they have the secret code_verifier on the redeem_token() call.
The code_challenge == sha256(code_verifier). You will share the code_challenge at the start of the flow.
Oauth's PKCE verifies the continuity of the flow as it is essentially a saga(multi-step process). For example you can initiate oauth access grant request multiple times with the same data, but PKCE ensures that each of those initiations can be individually identified. Do not confuse PKCE with state field, which is for XSS and has no obfuscation.
Just to be clear, the PKCE secret can be the same for each initiation, but in the end its goal is to ensure that the first request matches with the last one. And yes, there is "plain" PKCE method but that is just for testing. SHA256 is the default one used to obfuscate the secret.
I also think these are very similar. The main difference in my view is that the state parameter is checked by the client, while PKCE is checked by the server.
I run an authentication server and requiring PKCE allows me to make sure that XSS protection is handled for all clients.
I think one point of PKCE is that the oauth token is never sent to the client (it is exchanged on the backchannel), so it theoretically is more protected.
Of course if you trust the client (no bad browser extensions, updated browser) and have good TLS settings and no MITM risk and make sure the your IDs are single-use then it seems like that should be fine.
For this sort of use-case v4 might be better. It has more randomness and you will probably delete the old ids as soon as they are used anyway, so the indexed space will probably be small.
Yeah, I'd say that sounds fine. Since these are supposed to be used within a short time it'd also be easy to cleanup unused ones more then 5mins old or so.
> But much of the recommendations say to use the counter as a heuristic rather than evidence of a cloned authenticator because there are many legitimate reasons the counter can be wrong.
I'm curious on why there would be any legitimate reason for that. Security wise it should not happen, it's just some implementations being crappy or some bad practice like reusing same passkey with different devices ?
How to add passkeybot support to your site, according to their official guide:
start
(1) Copy / paste example_http_server into your LLM of choice (use a paid/good model).
(2) Prompt: Implement the HTTP handlers here for my project,..
Um, no? How about you give me real instructions on how to do it? I’m not going to delegate a security-critical task to an LLM. And since I need to review it carefully myself anyway, I might as well write it all by hand, right? Like, the whole premise is I just need to implement a couple of webhooks.
Yes, that is true, I was assuming that any LLM code was going to be checked by the developer. Step 7 in the guide is "review your code and ensure the important logic commented in the example server is still present".
The LLM is only for converting the JS based example code into your language X and HTTP framework Y (instead of giving example code for every combination of X and Y).
The standard implementation is in a single file `http_server.ts`, which is around 200 lines of well commented code, with important logic commented (around 5 lines). The example code can be run locally with a few commands.
The repo also contains a sequence diagram [1], a description of the HTTP handlers needed [2], and a live demo [3] where you can see the request/responses.
Thanks for your feedback I have made this clearer in the readme.
It's absolutely hilarious that someone would think that this passes for API docs nowdays. Still it's good to know what to avoid on the very first glance.
It's also a bit of a "bootstrapping" issue. How does anyone expect the AIs to learn to do things correctly if the instructions are not published for them to pick up during training?
This is like those "contact your system admin" error messages. I am the system admin!
I think it's good. Quite frankly, it's the better experience to be given the right prompts to onboard into something than having to guess that the inputs are the right for the LLM.
Why? Passwords can be remembered and entered on other devices for recovery. The plethora of passkeys out there cannot.
A bit the same why although I love the keychain in macOS, it also makes me uncomfortable. Lose your phone and laptop in a theft or fire and you are locked out from your Apple account. Goodbye online presence.
That's exactly the issue I have with passkeys. All that lockin to big tech. I tried bit warden but most sites with passkeys didn't work with it (like Amazon and PayPal). And on android it only wants to use the Google version (I don't use a Google account on my phone so that's not possible).
It does not work for me on my Linux PC with Firefox, PayPal simply refuses to enrol passkeys and Amazon tries but then gives an error. I haven't tried chromium as I don't have it installed.
I'll give it another try though. The last time was 1 year ago. I don't normally use Bitwarden so I have to set it up from scratch with vaultwarden etc.
This is probably a Linux issue. Mac OS and Windows implement the FIDO2 Platform API, which allows them to act as authenticators themselves. Linux does not. See https://github.com/linux-credentials.
Bitwarden works just fine for Amazon. Works on my phone too. Even when supplying passkeys over QR code+Bluetooth to another computer, Bitwarden's Android integration works flawlessly.
I do believe you need Android 14 for that, though, so if your phone has been abandoned by its manufacturer/your ROM of choice, it'll break.
If Bitwarden is bugged out on your computer/phone for whatever reason, there are also alternatives like 1Password.
Hm I should try it again, the last time was about a year ago, maybe a little more. I don't normally use bitwarden so I have to set it all up with vaultwarden to make it work.
Is it possible now to export the passkey private key though? That was another thing at the time, apparently the fido consortium didn't want keys to be exportable.
But I'll try it again, good point. I think with paypal the issue was also that they refuse passkeys in firefox and I don't use chrome so I was stuck there too. With Amazon it tried to enroll me but I got a bunch of errors.
The "standard" answer is that you should either use synced passkeys, or enroll multiple passkeys with the provider. The problem is that some providers (e.g. Paypal, some banks) only support one passkey, and synced passkeys aren't supposed to be trusted for attestation (unless they're synced by Apple/Google/Microsoft).
And every couple of days we see a post or a tweet about "Google/Apple/Microsoft just nuked my account with no notice and no recourse" so trusting them to sync passkeys rightfully makes some people nervous.
There are two problems with passwords. Reuse, and site breaches. The solution to the former is the same as passkeys: credential managers. Passkeys genuinely solve the second, in exchange for a vastly less comprehensible system (see all the uncertainty people have even here on HN) that doesn't support many of the ways people want to use authentication tokens.
The problem with this is requiring everyone to own a device with a secure enclave or similar hardware capabilities because some people are prone to being phished. Let me choose the level of risk I find acceptable.
Passkeys don't require it, but relying-parties may: https://github.com/keepassxreboot/keepassxc/issues/10407#iss... If enough RPs ban clients that let users manage their own data in the name of "security," then it is effectively required by passkeys. The passkey spec could have been written to be resilient against this type of abuse, but instead this abuse is explicitly considered a feature of the spec.
Are there any credential managers that don't validate the domain with passwords? Sure, there are issues with PSL subdomain matching, but at the end of the day it's good enough in the real world. All the other stuff (MITM, malicious site, etc) falls under the other case I already mentioned.
It's security, so we're not discussing impossibility. You can still phish a passkey, we're just hoping the cryptography is good enough that it remains astronomically unlikely to succeed. Since we're all reasonable people, that chance is low enough that we're fine accepting it. What I'm saying is that the chance with passwords is still low enough that I'm fine accepting, even though it's much higher than the cryptographic security of passkeys. We're simply disagreeing about where we draw the line of "good enough".
You crack the private key and forge the challenge? Maybe the other IDs sent alongside it are hard to get for some reason, but the security of passkeys comes down to the cryptography. Cryptography can always be broken, but a good cryptosystem makes the probability low enough that any reasonable person considers it good enough.
If you trust that the cryptography employed in passkeys is effectively unbreakable, then it follows that for all intents and purposes, passkeys cannot be phished. It’s the same thing as trusting that your browsing sessions cannot be MITMed because the end to end encryption is sufficiently strong.
That's not what phishing is. Phishing is convincing someone to give you a credential with a page that looks like the one they're supposed to give the credential on. Passkeys cannot be phished.
They must be paired with an alternative mechanism, unless you plan to unperson everyone who accidentally drops their phone in a river (this may be the plan for high-security services but it can't be the plan in general) and that mechanism can be phished.
Session cookies can't be phished either, so why aren't those sufficient?
Passkeys work well with password manager. The password manager also stores the long random password to get in without passkey. The advantage is that passkeys are immune to phishing. Sites also turn off 2FA for passkeys which reduces the hassle.
I think it's more than fair to document that some implementations lie about their intentional violation of the spec, even if that violation is done to make the login process smoother.
Still, I've never seen a website try to block Bitwarden's passkey management (though I've had plenty of issues because of its partial implementation of the API, especially in early versions) despite its spec violations.
For some of the implementations, user verification is a massive pain (as browser extensions often only have long and complicated passwords to authenticate) but for KeepassXC a quick and simple fingerprint/facial scan is an option, as it already offers integration into the native OS biometrics anyway.
> Still, I've never seen a website try to block Bitwarden's passkey management
Ideally it shouldn't be possible, or at least it should clearly be an ugly hack for a website to be doing something like this. Instead the spec authors explicitly endorse blocking clients that they feel are non-compliant. I'm not going to use a login spec that encourages websites to ban me because of the software I choose to use.
> for KeepassXC a quick and simple fingerprint/facial scan is an option, as it already offers integration into the native OS biometrics anyway.
Man don't get me started on the passkey environment's bizarre obsession with biometrics. My desktop computer doesn't have a fingerprint reader or a camera, and if my OS (Arch Linux) supports that junk I've certainly got no interest in doing the work to set it up just so I can log in to a website.
Documenting is fine, but the passkey spec author has been recommending blacklisting these so they don't work. It will end in a situation where only the Apple, Google and Microsoft passkey managers are the only way to log into any website.
And I wish passkeys could cover all the use cases of passwords, yet here we are. Passwords are simple and well understood. Passkeys have all sorts of sharp edges that you won't discover until you're hurt by them.
Regarding PKCE, the way I remember it is that OAuth2 was deliberately designed to eliminate as much actual cryptography as possible, relying instead on same-origin and TLS security; PKCE is one of the few things that introduces an actual cryptography primitive.
The authenticator GUI only shows “sign in to your_domain.com”. It never allows a more general “sign this content for your_domain.com”. E.g. “sign this transaction request to move £50 to Bob's account”.
That is why you should ship a pristine HTML+CSS+JS environment that can use subtle web crypto. YOU show what is being signed. And then the device can sign its hash using the secure enclave.
And you CAN do attestation even on consumer devices, by using the Device or AppAttest framework (I think that’s what it’s called). I did it myself in our app. It does show up 100% of the time but when it does it’s useful.
PS: being the web3 / blockchain geek that I am, I will tell you stuff that triggers anticryptobros on HN.
The Web3 ecosystem already has a standard called EIP712 for signing structured data. If you want to stick to standards, use that!
The secure enclaves all use P-256 (sometimes called R-256) while Bitcoin / Web3 uses K-256 (the Koeblitz curve, they distrust the NIST curve or whatever).
So that means you’re going to have to use Abstract Accounts and the new precompiled smart contracts to verify P256 signatures, which only Binance Smart Chain and a handful of other chains have deployed. Luckily BSC is the most widely used chain by volume and has plenty of money sloshing around so you can build your trustless programs there. If you want to be totally trustless — LET THE SMART CONTRACTS GENERATE THE CHALLENGE TO BE SIGNED BY THE AUTHENTICATOR. Then have it sign the temporary k256 public key (from the keypair) to use, as long as your session is open you can then add use your private key to sign transactions. As usual, do this for small amounts per day, transactions that move larger amounts should still require use of multisig keys etc.)
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
If you're using Firefox, it's a known bug and you can fix it by reverting the bitwarden extension and then wait for the fix.
I read this thinking "The BEST security is the WORST usability, and vice versa"
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.
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.
Yeah, the passkey provider management is absolutely horrendous and is the biggest blocker to passkey adoption in my eyes. I have 3 different sources (iCloud keychain, Yubikey, and Enpass) and in the best case it's some extra clicks like you mention, in the worst case it just simply won't let me select the correct provider.
I've resigned to registering a passkey into all of my providers and just letting the most platform native option win for now.
Apple does have an API to allow third parties to be used to store passwords and passkeys and they show up during the standard flow from a browser.
I remember once I was working for a big tech and we had windows computers. I tried to use Hello so I could login with my fingerprint. It broke outlook for some reason. So I switched to a Yubi key since they were offering.
Every login was the same: fails -> try again or try different method -> list of methods (including "security key") -> ok -> tap security key -> ok
It would not let me set the key as the default and there were two unnecessary clicks. The box literally only had a single button (besides the standard x on the window)! It was absolutely infuriating.
I'm with you. I don't believe these companies are actually trying to create the best solutions. And you can absolutely see that when you try to move from one ecosystem to another.
Look at my problem again and now consider had I been using my iCloud key and wanted to login from my Linux machine. It literally wouldn't be possible!
If your desktop browser has Bluetooth access you can scan a barcode with an iPhone.
This is the problem when UX guidelines are not part of the standard.
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.
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.
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?!
Which Linux? And are you saying Windows an Linux options are better or worse?
Why would a website leave you with an account but no way to log in aside from the account recovery procedure?
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.
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.
[1] https://developer.chrome.com/blog/digital-credentials-api-sh...
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.
As an American citizen, I had to upload my passport to get an ETA before flying into the UK this year.
https://www.gov.uk/eta
I also uploaded my passport to Delta to make traveling to both Costa Rica and London faster this year.
https://www.delta.com/us/en/travel-planning-center/know-befo...
The UK law is age verification not identity verification. Now, everyone in practice has collapsed that distinction, whether from incompetence or malice..
Age verification inevitably turns into identity verification. And this is by design. Age verification obviously is the excuse to implement identity verification.
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.
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.
until your gov decides that websites need to age-check everyone with the equivalent of showing some ID...
From my perspective we can talk about that when it actually happens. No need to slide on that slippery slope just yet, or at least, not in my neighbourhood...
Or corpos decide the time is ripe to force users to do it, so they can better optimize their surveillance targeting. Google has been nagging me with a periodic Android popup for like a decade to "add my birthday to help them comply with the law". Eventually that tack of borderline misleading will turn into an outright demand.
In the end we all are allowed to just not use a product... aren't we? Vote with your wallet is still possible.
No? A few percent of people dissenting doesn't move the needle for the company analysts, all the "competitors" tend to move in lock step since their managements are all tuned into the same memestream, and using such systems has steadily become more de facto mandatory for many previously-unrelated tasks.
I don't want to "move the needle", I just want to not support scummy companies. It sounded like you did too, but my mistake.
I don't know what you mean? My first point was just about how our individual behavior is not going to affect companies' decisions. The subsequent points were about how it's becoming increasingly harder to avoid supporting any scummy companies.
And the more this behavior is normalized, the easier it is for governments to make it illegal for any site to not demand users' government-registered identities.
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.
Thanks for that!
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.
[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...
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.
I don't see where he is threatening anybody? He's just stating the obvious. If you promise to store a key in a non-exportable format and then create a big export button, websites won't trust your software.
> What happens if my PC goes down and I couldn't export my data? I just can't log in anywhere?
Then you follow the procedure you would follow for when you'd forget your password. Probably a password reset through email, maybe calling customer support. Or if you have it set up, you could use the passkey set up on your phone or Yubikey or whatever to log in and create a new password on your new PC.
Passkeys aren't passwords, that's the whole point. It's modelled after the "something you have" factor, not "something you know". If you're finding workarounds to violate the security design, you're not gaining any advantage by using passkeys. Just use a password if you want to use a password.
> If you're finding workarounds to violate the security design, you're not gaining any advantage by using passkeys.
The trouble is, if websites are allowed/encouraged to ban clients, then the advantages you're talking about come with the downside of hard-tying yourself to one of 3 US-based Big Tech companies, because those will be the only ones who will ship clients declared "secure." That's not a trade-off I'm willing to make for something as critical as my service logins. You can already see this happening, almost every article talking about passkeys assumes you're logging in with an Apple, Google, or Microsoft device.
> Then you follow the procedure you would follow for when you'd forget your password. Probably a password reset through email, maybe calling customer support.
This is a downgrade from passwords (and exportable passkeys), where I can just restore it from a backup.
> Just use a password if you want to use a password.
Yeah, that's what I plan to keep doing, unfortunately. What I'm worried about is a password-less future where that's no longer an option and we all have to submit to using one of Android, iOS, or Windows to log in to everything because those are the only clients that can be trusted(TM) to handle the user's data as the big tech companies and governments desire it to be handled. This is a dark future.
You already need to submit to iOS or stock Android for a myriad of banking or government apps that use remote attestation to verify that you are running "untampered" software.
Remote attestation is evil.
FWIW this has not been my experience in the US, I've always been able to use websites for these things. I use my phone for almost nothing important since I don't trust it. But yes, I fear we are heading in that direction too.
I keep seeing this where? What banks don’t allow you to go to their website and use them from your phone? Which government apps don’t also have websites?
Not in the western countries yet, I guess. I live in Thailand and have accounts in two banks and both of them only allow usage through an app that's only available through the App/Play store. Android version of Krungthai's bank app freaks out if you have developer settings enabled (even without changing anything, just enabling the access is enough to lock you out). And to use that app in the first place, you have to go to a branch and have staff set the app for, as passing the facial scan checks is impossible for foreigners.
Several German banks (at least mine, one of the bigger ones) exclusively have you use an app for 2FA, you can still log via the website if you are lucky (as long as you have that one saved) but not do any transactions. So I would call that required.
> I don't see where he is threatening anybody?
The threat he relayed was more serious than the threat he made. But it is a threat when a person with influence suggests they may support a punishment.
> If you promise to store a key in a non-exportable format
There was no such promise. The people who wish Passkeys to replace passwords did not demand it yet even.
That's what I still don't understand. Why is "something you have" deemed more secure than "something you know". For a while everyone was harping on MFA, but suddenly passkeys came along and now SFA is fine as long as it's a passkey?
If I lose the device that has all my passkeys, I wouldn't be able to login into my emails either.
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.
Both things can be true:
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 agree with this, but I think the spec author's public statements means we don't need to give them the benefit of the doubt. People have repeatedly pointed out how this will result in vendor lock-in, and their response is either "yep, working as intended" or "we don't want to talk about this anymore." They're just steamrolling ahead with support from all the Big Tech companies. It's a really ugly situation =/
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.
>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.
Thank you, you have been the first person to articulate why passkeys are actually an advantage. Everyone else I've read from was focusing on the client side and there I really don't see a significant advantage. In fact it seems it's a downgrade from MFA, so I never understood the push for passkeys.
This is very well put, thank you (though I think you got a little needlessly aggro at the end :) ). A big part of why I find this situation so frustrating is passkeys are such a cool technology and genuinely a big improvement over passwords. I even spent a whole day writing a big article about how cool they are! But the big tech company lock-in stuff is so obvious, and so strongly supported by the spec authors and the passkey community, that it's hard to see it as unintentional. It completely poisons the technology, and that sucks because I really do want to use it.
>This is very well put, thank you (though I think you got a little needlessly aggro at the end :) ).
My apologies to GP if it came across as too personally aggro, I did mention the corps and their walled gardens to try to be clear on the focus, but the situation does really make me absolutely furious and also truly sad. This should have been such a simple, universal win/win/win that made everything better for everyone. But as you say:
>and so strongly supported by the spec authors and the passkey community, that it's hard to see it as unintentional. It completely poisons the technology, and that sucks because I really do want to use it.
Yeah, 110%. I'm one of the very few who actually tried to use certificates for web authentication back in the 00s, and it did work pretty darn well surprisingly! There were even a few commercial web services that tried it out like the now defunct StartSSL. It was just the whole flow around it was too clunky for regular people and needed some additional standardization and polish. If only the right catalyst had happened to make it a priority in the 2000s it might well have been done in a lasting good way that'd then be too sticky and entrenched to fuck with now. It's depressing to see it being hijacked and poisoned like it has been :(.
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.
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.
By all means, make a proposal to the FIDO Alliance that solves all these problems without introducing new ones. You're going to have to anticipate all the objections and be prepared to answer them, though.
I'm not the one trying to push a new standard, but sure, I'll do it for them. Explicitly allow users to export and back up their private keys in a documented file format, make client banning hard/discouraged, and no longer maintain a naughty client list. That's it.
Doesn't doing so necessarily lock out all the users using that client?
It would, yes. Thus it’s an action I would only recommend if doing so would help prevent serious injury to their customers. If it comes down to a choice between locking a customer out and having, say, their money stolen, then the scale tips towards safety.
Perhaps, but then (as always) we're back to the security of the recovery workflow.
Apple doesn't do attestation, so effectively this feature is dead in the water.
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.
No, Apple can't suddenly start doing attestation in the future by default because that would instantly kill all the passkeys that have already been created on Apple devices without attestation. It would be as if a home security company went around and changed all the locks they had installed on their customers' front doors. It would be instant suicide as a trusted vendor.
Isn’t that just like people said in 2008 now that therd is a Mac App Store “any day now” that will be the only way to get apps on the Mac?
> 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.
it's possible with CPU secure attestation, but it's not something you will encounter on regular personal computers.
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
Apple is already shipping remote attestation in Safari in the form of Private Access Tokens (https://developer.apple.com/news/?id=huqjyh7k), though Cloudflare's trial for that has ended. Safari authenticates and attests itself against Apple, who hands out tokens to your browser, which in turn get used to bypass CAPTCHAs and other anti spam filters.
There's no direct remote attestation implementation for passkeys yet, but remote attestation for web browsers has been around for a few years now.
> remote attestation for web browsers has been around for a few years now.
May it always remain niche.
A world in which open source browsers are unusable for most people and new entries to the browser market are all but impossible sounds terrible.
there is no contradiction between open-source and attestation
linux is open-source and a very common attestation target
Ask anyone who has tried to run banking apps on GrapheneOS how that works out in practice.
GrapheneOS supports attestation. GrapheneOS even provides the sort of security guarantees that would make risk management types at banks happy, but it isn't popular enough for them to be motivated to support it as an attestation target.
Now imagine it was practical for websites to require attestation from browsers. How likely do you think it that all the major services would accept anything other than Chrome, Safari, and Edge?
In oauth2: when I /1 associate a random uuidv4 for each new flow with my user (server side), /2 stick that uuid into the state parameter, and then /3 look up my user with this on callback-endpoint execution. Isn't PKCE in that case redundant?
PKCE protects the auth token from interception by making it so that only your code that started the flow can redeem it by proving they have the secret code_verifier on the redeem_token() call.
The code_challenge == sha256(code_verifier). You will share the code_challenge at the start of the flow.
Oauth's PKCE verifies the continuity of the flow as it is essentially a saga(multi-step process). For example you can initiate oauth access grant request multiple times with the same data, but PKCE ensures that each of those initiations can be individually identified. Do not confuse PKCE with state field, which is for XSS and has no obfuscation.
Just to be clear, the PKCE secret can be the same for each initiation, but in the end its goal is to ensure that the first request matches with the last one. And yes, there is "plain" PKCE method but that is just for testing. SHA256 is the default one used to obfuscate the secret.
I also think these are very similar. The main difference in my view is that the state parameter is checked by the client, while PKCE is checked by the server.
I run an authentication server and requiring PKCE allows me to make sure that XSS protection is handled for all clients.
I think one point of PKCE is that the oauth token is never sent to the client (it is exchanged on the backchannel), so it theoretically is more protected.
Of course if you trust the client (no bad browser extensions, updated browser) and have good TLS settings and no MITM risk and make sure the your IDs are single-use then it seems like that should be fine.
If you can, switch to uuid v7 if you're indexing by that id. Performance improvement while still not being sequential IDs.
For this sort of use-case v4 might be better. It has more randomness and you will probably delete the old ids as soon as they are used anyway, so the indexed space will probably be small.
How small is small, and how often is that state checked?
I guess it's probably not tracking tons of IDs like tracking packet state through a network device.
Even a few million (max) UUIDv4 is probably fine then, yeah?
Yeah, I'd say that sounds fine. Since these are supposed to be used within a short time it'd also be easy to cleanup unused ones more then 5mins old or so.
> But much of the recommendations say to use the counter as a heuristic rather than evidence of a cloned authenticator because there are many legitimate reasons the counter can be wrong.
I'm curious on why there would be any legitimate reason for that. Security wise it should not happen, it's just some implementations being crappy or some bad practice like reusing same passkey with different devices ?
How to add passkeybot support to your site, according to their official guide:
start
(1) Copy / paste example_http_server into your LLM of choice (use a paid/good model). (2) Prompt: Implement the HTTP handlers here for my project,..
Um, no? How about you give me real instructions on how to do it? I’m not going to delegate a security-critical task to an LLM. And since I need to review it carefully myself anyway, I might as well write it all by hand, right? Like, the whole premise is I just need to implement a couple of webhooks.
Yes, that is true, I was assuming that any LLM code was going to be checked by the developer. Step 7 in the guide is "review your code and ensure the important logic commented in the example server is still present".
The LLM is only for converting the JS based example code into your language X and HTTP framework Y (instead of giving example code for every combination of X and Y).
The standard implementation is in a single file `http_server.ts`, which is around 200 lines of well commented code, with important logic commented (around 5 lines). The example code can be run locally with a few commands.
The repo also contains a sequence diagram [1], a description of the HTTP handlers needed [2], and a live demo [3] where you can see the request/responses.
Thanks for your feedback I have made this clearer in the readme.
- [1] https://github.com/emadda/passkeybot/tree/master?tab=readme-...
- [2] https://github.com/emadda/passkeybot/tree/master?tab=readme-...
- [3] https://demo.enzom.dev/
It's absolutely hilarious that someone would think that this passes for API docs nowdays. Still it's good to know what to avoid on the very first glance.
It's also a bit of a "bootstrapping" issue. How does anyone expect the AIs to learn to do things correctly if the instructions are not published for them to pick up during training?
This is like those "contact your system admin" error messages. I am the system admin!
I think it's good. Quite frankly, it's the better experience to be given the right prompts to onboard into something than having to guess that the inputs are the right for the LLM.
If someone is writing authentication code and they think it's smart to outsource that to spicy autocomplete, the only "prompt" they need is:
"Hey chat bot friendo, where's the nearest hand-written 'help wanted' sign in the door of a coffee shop? I need a new career path"
BTW, if you're looking for something minimal that you can self host, say for a home lab environment, I landed on Pocket ID:
https://pocket-id.org/
Learning and building an outsourced security system at the same time ..... urgh.
For coders, building can be a great source of learning.
Example: this article.
i wish passkeys could replace passwords, not suppliment them
Why? Passwords can be remembered and entered on other devices for recovery. The plethora of passkeys out there cannot.
A bit the same why although I love the keychain in macOS, it also makes me uncomfortable. Lose your phone and laptop in a theft or fire and you are locked out from your Apple account. Goodbye online presence.
That's exactly the issue I have with passkeys. All that lockin to big tech. I tried bit warden but most sites with passkeys didn't work with it (like Amazon and PayPal). And on android it only wants to use the Google version (I don't use a Google account on my phone so that's not possible).
None of what you wrote is true though, is it?
Amazon, PayPal work just fine on my 3rd party 1Password extension. And it works just fine on Android as a default passkey provider as well.
It does not work for me on my Linux PC with Firefox, PayPal simply refuses to enrol passkeys and Amazon tries but then gives an error. I haven't tried chromium as I don't have it installed.
I'll give it another try though. The last time was 1 year ago. I don't normally use Bitwarden so I have to set it up from scratch with vaultwarden etc.
This is probably a Linux issue. Mac OS and Windows implement the FIDO2 Platform API, which allows them to act as authenticators themselves. Linux does not. See https://github.com/linux-credentials.
Bitwarden works just fine for Amazon. Works on my phone too. Even when supplying passkeys over QR code+Bluetooth to another computer, Bitwarden's Android integration works flawlessly.
I do believe you need Android 14 for that, though, so if your phone has been abandoned by its manufacturer/your ROM of choice, it'll break.
If Bitwarden is bugged out on your computer/phone for whatever reason, there are also alternatives like 1Password.
Hm I should try it again, the last time was about a year ago, maybe a little more. I don't normally use bitwarden so I have to set it all up with vaultwarden to make it work.
Is it possible now to export the passkey private key though? That was another thing at the time, apparently the fido consortium didn't want keys to be exportable.
But I'll try it again, good point. I think with paypal the issue was also that they refuse passkeys in firefox and I don't use chrome so I was stuck there too. With Amazon it tried to enroll me but I got a bunch of errors.
The "standard" answer is that you should either use synced passkeys, or enroll multiple passkeys with the provider. The problem is that some providers (e.g. Paypal, some banks) only support one passkey, and synced passkeys aren't supposed to be trusted for attestation (unless they're synced by Apple/Google/Microsoft).
And every couple of days we see a post or a tweet about "Google/Apple/Microsoft just nuked my account with no notice and no recourse" so trusting them to sync passkeys rightfully makes some people nervous.
Whereas we never see a horror story involving passwords.
There are two problems with passwords. Reuse, and site breaches. The solution to the former is the same as passkeys: credential managers. Passkeys genuinely solve the second, in exchange for a vastly less comprehensible system (see all the uncertainty people have even here on HN) that doesn't support many of the ways people want to use authentication tokens.
No, the biggest issue with passwords is phishing. You can't phish a passkey.
The problem with this is requiring everyone to own a device with a secure enclave or similar hardware capabilities because some people are prone to being phished. Let me choose the level of risk I find acceptable.
Passkeys don't require this.
How else would you make the private key unexportable and the passkey uncopyable?
You wouldn't, and still passkeys don't require this.
Passkeys don't require it, but relying-parties may: https://github.com/keepassxreboot/keepassxc/issues/10407#iss... If enough RPs ban clients that let users manage their own data in the name of "security," then it is effectively required by passkeys. The passkey spec could have been written to be resilient against this type of abuse, but instead this abuse is explicitly considered a feature of the spec.
Sort of. Passkeys push the phishing to the account recovery or passkey enrollment process.
How do you phish the account recovery or enrollment process?
Are there any credential managers that don't validate the domain with passwords? Sure, there are issues with PSL subdomain matching, but at the end of the day it's good enough in the real world. All the other stuff (MITM, malicious site, etc) falls under the other case I already mentioned.
There's a big difference between "generally doesn't get phished" and "it's impossible to be phished".
It's security, so we're not discussing impossibility. You can still phish a passkey, we're just hoping the cryptography is good enough that it remains astronomically unlikely to succeed. Since we're all reasonable people, that chance is low enough that we're fine accepting it. What I'm saying is that the chance with passwords is still low enough that I'm fine accepting, even though it's much higher than the cryptographic security of passkeys. We're simply disagreeing about where we draw the line of "good enough".
How can you phish a passkey?
You crack the private key and forge the challenge? Maybe the other IDs sent alongside it are hard to get for some reason, but the security of passkeys comes down to the cryptography. Cryptography can always be broken, but a good cryptosystem makes the probability low enough that any reasonable person considers it good enough.
If you trust that the cryptography employed in passkeys is effectively unbreakable, then it follows that for all intents and purposes, passkeys cannot be phished. It’s the same thing as trusting that your browsing sessions cannot be MITMed because the end to end encryption is sufficiently strong.
What happens if i drop my phone in a river? Am I unpersoned, or is there a way to recover all my accounts? Just phish that flow instead.
That's not what phishing is. Phishing is convincing someone to give you a credential with a page that looks like the one they're supposed to give the credential on. Passkeys cannot be phished.
They must be paired with an alternative mechanism, unless you plan to unperson everyone who accidentally drops their phone in a river (this may be the plan for high-security services but it can't be the plan in general) and that mechanism can be phished.
Session cookies can't be phished either, so why aren't those sufficient?
Passkeys work well with password manager. The password manager also stores the long random password to get in without passkey. The advantage is that passkeys are immune to phishing. Sites also turn off 2FA for passkeys which reduces the hassle.
Unless the spec authors declare your password manager to be on the official naughty list[1] and relying-parties choose to block clients on that list.
[1] https://passkeys.dev/docs/reference/known-issues/
I think it's more than fair to document that some implementations lie about their intentional violation of the spec, even if that violation is done to make the login process smoother.
Still, I've never seen a website try to block Bitwarden's passkey management (though I've had plenty of issues because of its partial implementation of the API, especially in early versions) despite its spec violations.
For some of the implementations, user verification is a massive pain (as browser extensions often only have long and complicated passwords to authenticate) but for KeepassXC a quick and simple fingerprint/facial scan is an option, as it already offers integration into the native OS biometrics anyway.
> Still, I've never seen a website try to block Bitwarden's passkey management
Ideally it shouldn't be possible, or at least it should clearly be an ugly hack for a website to be doing something like this. Instead the spec authors explicitly endorse blocking clients that they feel are non-compliant. I'm not going to use a login spec that encourages websites to ban me because of the software I choose to use.
> for KeepassXC a quick and simple fingerprint/facial scan is an option, as it already offers integration into the native OS biometrics anyway.
Man don't get me started on the passkey environment's bizarre obsession with biometrics. My desktop computer doesn't have a fingerprint reader or a camera, and if my OS (Arch Linux) supports that junk I've certainly got no interest in doing the work to set it up just so I can log in to a website.
Documenting is fine, but the passkey spec author has been recommending blacklisting these so they don't work. It will end in a situation where only the Apple, Google and Microsoft passkey managers are the only way to log into any website.
As I said earlier, this is functionally impossible because Apple devices don't offer device attestation data.
Then I look forward to them removing the anti-feature and no longer maintaining the naughty client list.
And I wish passkeys could cover all the use cases of passwords, yet here we are. Passwords are simple and well understood. Passkeys have all sorts of sharp edges that you won't discover until you're hurt by them.
Passwords are also simply phished, and many people have discovered those sharp edges by getting their accounts hacked.
Computerphile added a passkey video today https://www.youtube.com/watch?v=xYfiOnufBSk
I just watched this, it is very good.
Regarding PKCE, the way I remember it is that OAuth2 was deliberately designed to eliminate as much actual cryptography as possible, relying instead on same-origin and TLS security; PKCE is one of the few things that introduces an actual cryptography primitive.
The authenticator GUI only shows “sign in to your_domain.com”. It never allows a more general “sign this content for your_domain.com”. E.g. “sign this transaction request to move £50 to Bob's account”.
That is why you should ship a pristine HTML+CSS+JS environment that can use subtle web crypto. YOU show what is being signed. And then the device can sign its hash using the secure enclave.
And you CAN do attestation even on consumer devices, by using the Device or AppAttest framework (I think that’s what it’s called). I did it myself in our app. It does show up 100% of the time but when it does it’s useful.
PS: being the web3 / blockchain geek that I am, I will tell you stuff that triggers anticryptobros on HN.
The Web3 ecosystem already has a standard called EIP712 for signing structured data. If you want to stick to standards, use that!
The secure enclaves all use P-256 (sometimes called R-256) while Bitcoin / Web3 uses K-256 (the Koeblitz curve, they distrust the NIST curve or whatever).
So that means you’re going to have to use Abstract Accounts and the new precompiled smart contracts to verify P256 signatures, which only Binance Smart Chain and a handful of other chains have deployed. Luckily BSC is the most widely used chain by volume and has plenty of money sloshing around so you can build your trustless programs there. If you want to be totally trustless — LET THE SMART CONTRACTS GENERATE THE CHALLENGE TO BE SIGNED BY THE AUTHENTICATOR. Then have it sign the temporary k256 public key (from the keypair) to use, as long as your session is open you can then add use your private key to sign transactions. As usual, do this for small amounts per day, transactions that move larger amounts should still require use of multisig keys etc.)