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.
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.
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/
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.
> 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.
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?
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.
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.
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.)
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.
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?
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
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.
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.
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.
> 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 ?
26 comments
[ 2.9 ms ] story [ 48.0 ms ] threadMy 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.
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.
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/
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/
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.
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 run an authentication server and requiring PKCE allows me to make sure that XSS protection is handled for all clients.
The code_challenge == sha256(code_verifier). You will share the code_challenge at the start of the flow.
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.)
[1] Spec author quote: "To be very honest here, you risk having KeePassXC blocked by relying parties." https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
[2] https://www.smokingonabike.com/2025/01/04/passkey-marketing-...
[3] https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shatt...
I personally think the ability to export+import passkeys is a good thing from a backup point of view, but he's not wrong in suggesting that companies actually using the high security features of passkeys will eventually block software implementations like these.
This isn't about vendor lock-in. Nobody is asking for KeepassXC to remove passkey support. This is about security software implementing an API and not fulfilling the expectations that come with such an implementation. To quote the comment you linked:
> That's fine. Let determined people do that, but don't make it easy for a user to be tricked into handing over all of their credentials in clear text.
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
In terms of security, yes. But not in terms of convenience.
[1] https://developer.chrome.com/blog/digital-credentials-api-sh...
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.
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.
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 ?
https://pocket-id.org/