7 ms·

Things I learnt about passkeys when building passkeybot

173 points by emadda 9mo ago

BoppreH 9mo ago
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.
loloquwowndueo 9mo ago
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.
- gear54rus 9mo ago
  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.
  - jiggawatts 9mo ago
    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!
  - the_mitsuhiko 9mo ago
    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.
    - stephenr 9mo ago
      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"
- emadda 9mo ago
  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-ov-file#sequence-diagrams https://github.com/emadda/passkeybot/tree/master?tab=readme-... - [2] https://github.com/emadda/passkeybot/tree/master?tab=readme-ov-file#http-handlers-you-must-implement-on-your-server https://github.com/emadda/passkeybot/tree/master?tab=readme-... - [3] https://demo.enzom.dev/ https://demo.enzom.dev/
  - deleted 9mo ago
    [deleted]
ChrisMarshallNY 9mo ago
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/ https://littlegreenviper.com/series/passkeys/
tptacek 9mo ago
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.
boombapoom 9mo ago
i wish passkeys could replace passwords, not suppliment them
- deleted 9mo ago
  [deleted]
- spockz 9mo ago
  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.
  - wkat4242 9mo ago
    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).
    - izacus 9mo ago
      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.
      - wkat4242 9mo ago
        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.
        9mo ago
xg15 9mo ago
> 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.
- ajross 9mo ago
  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.
  - deleted 9mo ago
    [deleted]
  - machinationu 9mo ago
    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
smallnix 9mo ago
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?
- esseph 9mo ago
  If you can, switch to uuid v7 if you're indexing by that id. Performance improvement while still not being sequential IDs.
  - SahAssar 9mo ago
    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.
    - esseph 9mo ago
      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?
      - SahAssar 9mo ago
        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.
- SahAssar 9mo ago
  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.
EGreg 9mo ago
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.)
QGQBGdeZREunxLe 9mo ago
Computerphile added a passkey video today https://www.youtube.com/watch?v=xYfiOnufBSk https://www.youtube.com/watch?v=xYfiOnufBSk
- emadda 9mo ago
  I just watched this, it is very good.
coldpie 9mo ago
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#issuecomment-1994182200 https://github.com/keepassxreboot/keepassxc/issues/10407#iss... [2] https://www.smokingonabike.com/2025/01/04/passkey-marketing-is-lying-to-you/ https://www.smokingonabike.com/2025/01/04/passkey-marketing-... [3] https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shattered-dream/ https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shatt...
- yawaramin 9mo ago
  Apple doesn't do attestation, so effectively this feature is dead in the water.
  - lelandbatey 9mo ago
    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.
    - raw_anon_1111 9mo ago
      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?
    - yawaramin 9mo ago
      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.
godelski 9mo ago
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
- awesome_dude 9mo ago
  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.
  - jeroenhd 9mo ago
    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.
    - godelski 9mo ago
      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!
quantummagic 9mo ago
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-shipped https://developer.chrome.com/blog/digital-credentials-api-sh...
- jeroenhd 9mo ago
  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.
  - quantummagic 9mo ago
    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.
    - raw_anon_1111 9mo ago
      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 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-before-you-go/get-to-know-flyready https://www.delta.com/us/en/travel-planning-center/know-befo...
  - realusername 9mo ago
    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.
IgorPartola 9mo ago
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.
- bobbylarrybobby 9mo ago
  Why would a website leave you with an account but no way to log in aside from the account recovery procedure?
  - IgorPartola 9mo ago
    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.
- godelski 9mo ago
  > 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?!
wewewedxfgdf 9mo ago
Learning and building an outsourced security system at the same time ..... urgh.
- WolfeReader 9mo ago
  For coders, building can be a great source of learning. Example: this article.
arjie 9mo ago
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.
- ChadNauseam 9mo ago
  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)
  - arjie 9mo ago
    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.
- comex 9mo ago
  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).
PunchyHamster 9mo ago
> 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 ?
js2 9mo ago
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/ https://pocket-id.org/

173 points by emadda 9mo ago

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.

loloquwowndueo 9mo ago

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.

gear54rus 9mo ago
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.
- jiggawatts 9mo ago
  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!
- the_mitsuhiko 9mo ago
  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.
  - stephenr 9mo ago
    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"
emadda 9mo ago
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-ov-file#sequence-diagrams https://github.com/emadda/passkeybot/tree/master?tab=readme-... - [2] https://github.com/emadda/passkeybot/tree/master?tab=readme-ov-file#http-handlers-you-must-implement-on-your-server https://github.com/emadda/passkeybot/tree/master?tab=readme-... - [3] https://demo.enzom.dev/ https://demo.enzom.dev/
- deleted 9mo ago
  [deleted]

ChrisMarshallNY 9mo ago

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/ https://littlegreenviper.com/series/passkeys/

tptacek 9mo ago

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.

boombapoom 9mo ago

i wish passkeys could replace passwords, not suppliment them

deleted 9mo ago
[deleted]
spockz 9mo ago
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.
- wkat4242 9mo ago
  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).
  - izacus 9mo ago
    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.
    - wkat4242 9mo ago
      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.
      - 9mo ago

xg15 9mo ago

> 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.

ajross 9mo ago
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.
- deleted 9mo ago
  [deleted]
- machinationu 9mo ago
  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

smallnix 9mo ago

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?

esseph 9mo ago
If you can, switch to uuid v7 if you're indexing by that id. Performance improvement while still not being sequential IDs.
- SahAssar 9mo ago
  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.
  - esseph 9mo ago
    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?
    - SahAssar 9mo ago
      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.
SahAssar 9mo ago
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.

EGreg 9mo ago

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.)

QGQBGdeZREunxLe 9mo ago

Computerphile added a passkey video today https://www.youtube.com/watch?v=xYfiOnufBSk https://www.youtube.com/watch?v=xYfiOnufBSk

emadda 9mo ago
I just watched this, it is very good.

coldpie 9mo ago

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#issuecomment-1994182200 https://github.com/keepassxreboot/keepassxc/issues/10407#iss... [2] https://www.smokingonabike.com/2025/01/04/passkey-marketing-is-lying-to-you/ https://www.smokingonabike.com/2025/01/04/passkey-marketing-... [3] https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shattered-dream/ https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shatt...

yawaramin 9mo ago
Apple doesn't do attestation, so effectively this feature is dead in the water.
- lelandbatey 9mo ago
  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.
  - raw_anon_1111 9mo ago
    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?
  - yawaramin 9mo ago
    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.

godelski 9mo ago

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

awesome_dude 9mo ago
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.
- jeroenhd 9mo ago
  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.
  - godelski 9mo ago
    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!

quantummagic 9mo ago

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-shipped https://developer.chrome.com/blog/digital-credentials-api-sh...

jeroenhd 9mo ago
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.
- quantummagic 9mo ago
  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.
  - raw_anon_1111 9mo ago
    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 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-before-you-go/get-to-know-flyready https://www.delta.com/us/en/travel-planning-center/know-befo...
- realusername 9mo ago
  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.

IgorPartola 9mo ago

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.

bobbylarrybobby 9mo ago
Why would a website leave you with an account but no way to log in aside from the account recovery procedure?
- IgorPartola 9mo ago
  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.
godelski 9mo ago
> 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?!

wewewedxfgdf 9mo ago

Learning and building an outsourced security system at the same time ..... urgh.

WolfeReader 9mo ago
For coders, building can be a great source of learning. Example: this article.

arjie 9mo ago

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.

ChadNauseam 9mo ago
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)
- arjie 9mo ago
  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.
comex 9mo ago
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).

PunchyHamster 9mo ago

> 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 ?

js2 9mo ago

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/ https://pocket-id.org/