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

101–110 of 152 posts

Re: Things I learnt about passkeys when building passkeybot

#101

Post by pjc50 »

otterley wrote: post #66
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…

So if a client ever goes rogue someday (either intentionally or has been compromised) and starts shipping off private material to a malicious third party, you think relying parties shouldn’t have the option not to trust that client anymore?

Doesn't doing so necessarily lock out all the users using that client?

Re: Things I learnt about passkeys when building passkeybot

#102

Post by arccy »

mariusor wrote: post #98
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...

It's likely that the websites need your actual government issued credentials are not your twitters and your hacker news, but government websites that actually need to link the web user to the citizen. As an example my country has a portal that you use as a citizen to book appointments to government institutions, keeps you updated about the status of your requests, allows you to securely upload scans for additional do…

until your gov decides that websites need to age-check everyone with the equivalent of showing some ID...

Re: Things I learnt about passkeys when building passkeybot

#103

Post by IgorPartola »

bobbylarrybobby wrote: post #72
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…

Why would a website leave you with an account but no way to log in aside from the account recovery procedure?

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.

Re: Things I learnt about passkeys when building passkeybot

#104

Post by IgorPartola »

godelski wrote: post #86
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…

Which Linux? And are you saying Windows an Linux options are better or worse?

Re: Things I learnt about passkeys when building passkeybot

#105

Post by immibis »

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

What happens if i drop my phone in a river? Am I unpersoned, or is there a way to recover all my accounts? Just phish that flow instead.

Re: Things I learnt about passkeys when building passkeybot

#106

Post by immibis »

stavros wrote: post #80
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.

That's not what phishing is. Phishing is convincing someone to give you a credential with a page that looks like the one they're supposed to give the credential on. Passkeys cannot be phished.

They must be paired with an alternative mechanism, unless you plan to unperson everyone who accidentally drops their phone in a river (this may be the plan for high-security services but it can't be the plan in general) and that mechanism can be phished.

Session cookies can't be phished either, so why aren't those sufficient?

Re: Things I learnt about passkeys when building passkeybot

#107

Post by immibis »

jeroenhd wrote: post #49
coldpie wrote: post #30

Earlier quoted context omitted.

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/

I think it's more than fair to document that some implementations lie about their intentional violation of the spec, even if that violation is done to make the login process smoother. Still, I've never seen a website try to block Bitwarden's passkey management (though I've had plenty of issues because of its partial implementation of the API, especially in early versions) despite its spec violations. For some of the…

Documenting is fine, but the passkey spec author has been recommending blacklisting these so they don't work. It will end in a situation where only the Apple, Google and Microsoft passkey managers are the only way to log into any website.

Re: Things I learnt about passkeys when building passkeybot

#108

Post by emadda »

loloquwowndueo wrote: post #3

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…

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

- [2] https://github.com/emadda/passkeybot/tree/master?tab=readme-...

- [3] https://demo.enzom.dev/

Re: Things I learnt about passkeys when building passkeybot

#109

Post by SahAssar »

esseph wrote: post #83
SahAssar wrote: post #22

Earlier quoted context omitted.

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?

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.

Re: Things I learnt about passkeys when building passkeybot

#110

Post by wink »

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?

Several German banks (at least mine, one of the bigger ones) exclusively have you use an app for 2FA, you can still log via the website if you are lucky (as long as you have that one saved) but not do any transactions. So I would call that required.
Post reply on HN