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

51–60 of 152 posts

Re: Things I learnt about passkeys when building passkeybot

#51

Post by jeroenhd »

coldpie wrote: post #45
jeroenhd wrote: post #43

Earlier quoted context omitted.

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…

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 email, maybe calling customer support. Or if you have it set up, you could use the passkey set up on your phone or Yubikey or whatever to log in and create a new password on your new PC.

Passkeys aren't passwords, that's the whole point. It's modelled after the "something you have" factor, not "something you know". If you're finding workarounds to violate the security design, you're not gaining any advantage by using passkeys. Just use a password if you want to use a password.

Re: Things I learnt about passkeys when building passkeybot

#52

Post by coldpie »

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…

> Still, I've never seen a website try to block Bitwarden's passkey management

Ideally it shouldn't be possible, or at least it should clearly be an ugly hack for a website to be doing something like this. Instead the spec authors explicitly endorse blocking clients that they feel are non-compliant. I'm not going to use a login spec that encourages websites to ban me because of the software I choose to use.

> for KeepassXC a quick and simple fingerprint/facial scan is an option, as it already offers integration into the native OS biometrics anyway.

Man don't get me started on the passkey environment's bizarre obsession with biometrics. My desktop computer doesn't have a fingerprint reader or a camera, and if my OS (Arch Linux) supports that junk I've certainly got no interest in doing the work to set it up just so I can log in to a website.

Re: Things I learnt about passkeys when building passkeybot

#53

Post by jeroenhd »

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.

Re: Things I learnt about passkeys when building passkeybot

#54

Post by AlotOfReading »

stavros wrote: post #40
AlotOfReading wrote: post #37

Earlier quoted context omitted.

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?

You crack the private key and forge the challenge? Maybe the other IDs sent alongside it are hard to get for some reason, but the security of passkeys comes down to the cryptography. Cryptography can always be broken, but a good cryptosystem makes the probability low enough that any reasonable person considers it good enough.

Re: Things I learnt about passkeys when building passkeybot

#55

Post by jeroenhd »

awesome_dude wrote: post #50
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.

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 respond and throw itself front and center. It's a terrible hack but it works on every browser at the very least.

If these companies cared about their users more than they cared about throwing up walled gardens, they wouldn't put a USB key behind "Choose another method" -> "Dedicated device" -> "Security key" -> "Confirm" while offering one-click login with their cloud account. And they would offer a proper API for third party applications to integrate into the native passkey storage.

Re: Things I learnt about passkeys when building passkeybot

#56

Post by nabogh »

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…

I agree with you but the whole thing makes me uncomfortable. We're definitely making it easier for these security conscious companies to do vendor lock in if we encourage passkey use.

Re: Things I learnt about passkeys when building passkeybot

#57

Post by coldpie »

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 you're finding workarounds to violate the security design, you're not gaining any advantage by using passkeys.

The trouble is, if websites are allowed/encouraged to ban clients, then the advantages you're talking about come with the downside of hard-tying yourself to one of 3 US-based Big Tech companies, because those will be the only ones who will ship clients declared "secure." That's not a trade-off I'm willing to make for something as critical as my service logins. You can already see this happening, almost every article talking about passkeys assumes you're logging in with an Apple, Google, or Microsoft device.

> Then you follow the procedure you would follow for when you'd forget your password. Probably a password reset through email, maybe calling customer support.

This is a downgrade from passwords (and exportable passkeys), where I can just restore it from a backup.

> Just use a password if you want to use a password.

Yeah, that's what I plan to keep doing, unfortunately. What I'm worried about is a password-less future where that's no longer an option and we all have to submit to using one of Android, iOS, or Windows to log in to everything because those are the only clients that can be trusted(TM) to handle the user's data as the big tech companies and governments desire it to be handled. This is a dark future.

Re: Things I learnt about passkeys when building passkeybot

#58

Post by Magnusmaster »

coldpie wrote: post #57
jeroenhd wrote: post #51

Earlier quoted context omitted.

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 you're finding workarounds to violate the security design, you're not gaining any advantage by using passkeys. The trouble is, if websites are allowed/encouraged to ban clients, then the advantages you're talking about come with the downside of hard-tying yourself to one of 3 US-based Big Tech companies, because those will be the only ones who will ship clients declared "secure." That's not a trade-off I'm willi…

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.

Re: Things I learnt about passkeys when building passkeybot

#59

Post by stubish »

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…

But the natural result is vendor lock in. To stop exports of keys, sites will need a whitelist and secure method to verify the hardware or software implementation has not been tampered with. If an implementation is banned, the obvious solution is to allow it to pretend to be a non-banned implementation. Or admin level processes smuggling keys out of approved implementations. I don't think anyone wants an arms race, thus the vague threats to remove features that users are demanding before they will consider buying into the ecosystem.

Re: Things I learnt about passkeys when building passkeybot

#60

Post by coldpie »

Magnusmaster wrote: post #58
coldpie wrote: post #57

Earlier quoted context omitted.

> If you're finding workarounds to violate the security design, you're not gaining any advantage by using passkeys. The trouble is, if websites are allowed/encouraged to ban clients, then the advantages you're talking about come with the downside of hard-tying yourself to one of 3 US-based Big Tech companies, because those will be the only ones who will ship clients declared "secure." That's not a trade-off I'm willi…

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.

FWIW this has not been my experience in the US, I've always been able to use websites for these things. I use my phone for almost nothing important since I don't trust it. But yes, I fear we are heading in that direction too.
Post reply on HN