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

31–40 of 152 posts

Re: Things I learnt about passkeys when building passkeybot

#31

Post by stavros »

AlotOfReading wrote: post #29
stavros wrote: post #24

Earlier quoted context omitted.

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.

Re: Things I learnt about passkeys when building passkeybot

#32

Post by AlotOfReading »

stavros wrote: post #31
AlotOfReading wrote: post #29

Earlier quoted context omitted.

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.

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.

Re: Things I learnt about passkeys when building passkeybot

#33

Post by stavros »

AlotOfReading wrote: post #32
stavros wrote: post #31

Earlier quoted context omitted.

No, the biggest issue with passwords is phishing. You can't phish a passkey.

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

Re: Things I learnt about passkeys when building passkeybot

#34

Post by gethly »

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?

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.

Re: Things I learnt about passkeys when building passkeybot

#35

Post by yawaramin »

coldpie wrote: post #28

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…

Apple doesn't do attestation, so effectively this feature is dead in the water.

Re: Things I learnt about passkeys when building passkeybot

#36

Post by godelski »

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

Re: Things I learnt about passkeys when building passkeybot

#37

Post by AlotOfReading »

stavros wrote: post #33
AlotOfReading wrote: post #32

Earlier quoted context omitted.

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

Re: Things I learnt about passkeys when building passkeybot

#38

Post by yawaramin »

coldpie wrote: post #30
ianburrell wrote: post #27

Earlier quoted context omitted.

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/

As I said earlier, this is functionally impossible because Apple devices don't offer device attestation data.

Re: Things I learnt about passkeys when building passkeybot

#39

Post by yawaramin »

AlotOfReading wrote: post #11
boombapoom wrote: post #7

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.

Passwords are also simply phished, and many people have discovered those sharp edges by getting their accounts hacked.

Re: Things I learnt about passkeys when building passkeybot

#40

Post by stavros »

AlotOfReading wrote: post #37
stavros wrote: post #33

Earlier quoted context omitted.

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

How can you phish a passkey?
Post reply on HN