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

41–50 of 152 posts

Re: Things I learnt about passkeys when building passkeybot

#41

Post by lelandbatey »

yawaramin wrote: post #35
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.

Per the article, Apple does do attestation. By default attestation is off unless you have enterprise management turned on.

But the existence of attestation means Apple could at any time in the future make attestation on by default and suddenly our devices control our secrets more than we do.

Re: Things I learnt about passkeys when building passkeybot

#43

Post by jeroenhd »

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…

The point of passkeys is that they're unexportable. Software implementations like Bitwarden/KeepassXC/etc. making them exportable go right against the point of the protocols.

I personally think the ability to export+import passkeys is a good thing from a backup point of view, but he's not wrong in suggesting that companies actually using the high security features of passkeys will eventually block software implementations like these.

This isn't about vendor lock-in. Nobody is asking for KeepassXC to remove passkey support. This is about security software implementing an API and not fulfilling the expectations that come with such an implementation. To quote the comment you linked:

> That's fine. Let determined people do that, but don't make it easy for a user to be tricked into handing over all of their credentials in clear text.

Re: Things I learnt about passkeys when building passkeybot

#44

Post by jeroenhd »

machinationu wrote: post #23
ajross wrote: post #16

Earlier quoted context omitted.

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

Apple is already shipping remote attestation in Safari in the form of Private Access Tokens (https://developer.apple.com/news/?id=huqjyh7k), though Cloudflare's trial for that has ended. Safari authenticates and attests itself against Apple, who hands out tokens to your browser, which in turn get used to bypass CAPTCHAs and other anti spam filters.

There's no direct remote attestation implementation for passkeys yet, but remote attestation for web browsers has been around for a few years now.

Re: Things I learnt about passkeys when building passkeybot

#45

Post by coldpie »

jeroenhd wrote: post #43
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…

The point of passkeys is that they're unexportable. Software implementations like Bitwarden/KeepassXC/etc. making them exportable go right against the point of the protocols. I personally think the ability to export+import passkeys is a good thing from a backup point of view, but he's not wrong in suggesting that companies actually using the high security features of passkeys will eventually block software implementa…

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 not a "good thing," it's absolutely critical. If I can't back up my credentials in a location that I trust, then it's not an acceptable login method. What happens if my PC goes down and I couldn't export my data? I just can't log in anywhere? KeePassXC lets me do that, but the spec authors think it's appropriate to ban me for using it because it lets me manage my own data. That's bonkers.

Re: Things I learnt about passkeys when building passkeybot

#46

Post by jeroenhd »

wkat4242 wrote: post #13
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.

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

Bitwarden works just fine for Amazon. Works on my phone too. Even when supplying passkeys over QR code+Bluetooth to another computer, Bitwarden's Android integration works flawlessly.

I do believe you need Android 14 for that, though, so if your phone has been abandoned by its manufacturer/your ROM of choice, it'll break.

If Bitwarden is bugged out on your computer/phone for whatever reason, there are also alternatives like 1Password.

Re: Things I learnt about passkeys when building passkeybot

#47

Post by coldpie »

yawaramin wrote: post #38
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/

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

Then I look forward to them removing the anti-feature and no longer maintaining the naughty client list.

Re: Things I learnt about passkeys when building passkeybot

#48

Post by stephenr »

the_mitsuhiko wrote: post #17
gear54rus wrote: post #5

Earlier quoted context omitted.

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.

If someone is writing authentication code and they think it's smart to outsource that to spicy autocomplete, the only "prompt" they need is:

"Hey chat bot friendo, where's the nearest hand-written 'help wanted' sign in the door of a coffee shop? I need a new career path"

Re: Things I learnt about passkeys when building passkeybot

#49

Post by jeroenhd »

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/

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 implementations, user verification is a massive pain (as browser extensions often only have long and complicated passwords to authenticate) but for KeepassXC a quick and simple fingerprint/facial scan is an option, as it already offers integration into the native OS biometrics anyway.

Re: Things I learnt about passkeys when building passkeybot

#50

Post by awesome_dude »

godelski wrote: post #36

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

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.

Post reply on HN