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

81–90 of 152 posts

Re: Things I learnt about passkeys when building passkeybot

#81

Post by ximm »

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

Re: Things I learnt about passkeys when building passkeybot

#82

Post by ximm »

wkat4242 wrote: post #62
izacus wrote: post #18

Earlier quoted context omitted.

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.

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.

This is probably a Linux issue. Mac OS and Windows implement the FIDO2 Platform API, which allows them to act as authenticators themselves. Linux does not. See https://github.com/linux-credentials.

Re: Things I learnt about passkeys when building passkeybot

#83

Post by esseph »

SahAssar wrote: post #22
esseph wrote: post #19

Earlier quoted context omitted.

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.

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?

Re: Things I learnt about passkeys when building passkeybot

#84

Post by realusername »

jeroenhd wrote: post #53
quantummagic wrote: post #42

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

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.

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.

Re: Things I learnt about passkeys when building passkeybot

#85

Post by miohtama »

jeroenhd wrote: post #55
awesome_dude wrote: post #50

Earlier quoted context omitted.

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.

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

This is the problem when UX guidelines are not part of the standard.

Re: Things I learnt about passkeys when building passkeybot

#86

Post by godelski »

IgorPartola wrote: post #61

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

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

Re: Things I learnt about passkeys when building passkeybot

#87

Post by arjie »

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.

Re: Things I learnt about passkeys when building passkeybot

#89

Post by literallywho »

raw_anon_1111 wrote: post #77
Magnusmaster wrote: post #58

Earlier quoted context omitted.

You already need to submit to iOS or stock Android for a myriad of banking or government apps that use remote attestation to verify that you are running "untampered" software. Remote attestation is evil.

I keep seeing this where? What banks don’t allow you to go to their website and use them from your phone? Which government apps don’t also have websites?

Not in the western countries yet, I guess. I live in Thailand and have accounts in two banks and both of them only allow usage through an app that's only available through the App/Play store. Android version of Krungthai's bank app freaks out if you have developer settings enabled (even without changing anything, just enabling the access is enough to lock you out). And to use that app in the first place, you have to go to a branch and have staff set the app for, as passing the facial scan checks is impossible for foreigners.

Re: Things I learnt about passkeys when building passkeybot

#90

Post by literallywho »

jeroenhd wrote: post #51
coldpie wrote: post #45

Earlier quoted context omitted.

It's fine for them to make suggestions for projects to improve their software. The problem is threatening clients with being banned because they don't agree with those suggestions. If a website is able to ban me because of the passkey client I'm using, then I'm just not going to use passkeys. It's too unreliable. > personally think the ability to export+import passkeys is a good thing from a backup point of view It's…

I don't see where he is threatening anybody? He's just stating the obvious. If you promise to store a key in a non-exportable format and then create a big export button, websites won't trust your software. > What happens if my PC goes down and I couldn't export my data? I just can't log in anywhere? Then you follow the procedure you would follow for when you'd forget your password. Probably a password reset through e…

If I lose the device that has all my passkeys, I wouldn't be able to login into my emails either.
Post reply on HN