Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things I learnt about passkeys when building passkeybot

enzom.dev

Post reply on HN
Print view View original

21–30 of 152 posts

Re: Things I learnt about passkeys when building passkeybot

#21

Post by epaulson »

AlotOfReading wrote: post #14
spockz wrote: 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.

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.

Re: Things I learnt about passkeys when building passkeybot

#22

Post by SahAssar »

esseph wrote: post #19
smallnix wrote: post #15

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.

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.

Re: Things I learnt about passkeys when building passkeybot

#23

Post by machinationu »

ajross wrote: post #16
xg15 wrote: 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 yo…

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

Re: Things I learnt about passkeys when building passkeybot

#24

Post by stavros »

epaulson wrote: post #21
AlotOfReading wrote: post #14

Earlier quoted context omitted.

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.

Re: Things I learnt about passkeys when building passkeybot

#25

Post by SahAssar »

smallnix wrote: post #15

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?

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.

Re: Things I learnt about passkeys when building passkeybot

#27

Post by ianburrell »

spockz wrote: post #10
boombapoom wrote: post #7

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.

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.

Re: Things I learnt about passkeys when building passkeybot

#28

Post by coldpie »

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

Re: Things I learnt about passkeys when building passkeybot

#29

Post by AlotOfReading »

stavros wrote: post #24
epaulson wrote: post #21

Earlier quoted context omitted.

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.

Re: Things I learnt about passkeys when building passkeybot

#30

Post by coldpie »

ianburrell wrote: post #27
spockz wrote: 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.

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/

Post reply on HN