Live data from Hacker News

Things I learnt about passkeys when building passkeybot

enzom.dev

11–20 of 152 posts

Re: Things I learnt about passkeys when building passkeybot

#11

i wish passkeys could replace passwords, not suppliment them

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.

Re: Things I learnt about passkeys when building passkeybot

#12

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 mi…

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!

Re: Things I learnt about passkeys when building passkeybot

#13
post #10

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

Re: Things I learnt about passkeys when building passkeybot

#14
post #10

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.

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

Re: Things I learnt about passkeys when building passkeybot

#16
post #8

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

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.

Re: Things I learnt about passkeys when building passkeybot

#17

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 mi…

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.

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.

Re: Things I learnt about passkeys when building passkeybot

#18
post #10

Earlier quoted context omitted.

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.

Re: Things I learnt about passkeys when building passkeybot

#19

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?

If you can, switch to uuid v7 if you're indexing by that id. Performance improvement while still not being sequential IDs.

Re: Things I learnt about passkeys when building passkeybot

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

Post reply on HN