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

61–70 of 152 posts

Re: Things I learnt about passkeys when building passkeybot

#61

Post by IgorPartola »

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 list and manually remove it. I believe I was correctly using the JS API for signaling orphaned keys but the OS still wouldn’t remove it so it was a situation of having to educate the user to remove the orphaned key manually (and hoping the user doesn’t get confused and remove the wrong key). You also apparently can’t create more than one passkey for the same username and the same website. 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.

Overall it’s not terrible but I think these edge cases are going to keep biting people and need to be addressed in some way. And yes I understand that I could use a Yubikey or Bitwarden or some such but the point was that I wanted to see how this flow works for “normal” users who just use the iCloud Keychain and the experience leaves something to be desired.

Re: Things I learnt about passkeys when building passkeybot

#62

Post by wkat4242 »

izacus wrote: post #18
wkat4242 wrote: post #13

Earlier quoted context omitted.

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

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.

Re: Things I learnt about passkeys when building passkeybot

#63

Post by wkat4242 »

jeroenhd wrote: post #46
wkat4242 wrote: post #13

Earlier quoted context omitted.

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

Hm I should try it again, the last time was about a year ago, maybe a little more. I don't normally use bitwarden so I have to set it all up with vaultwarden to make it work.

Is it possible now to export the passkey private key though? That was another thing at the time, apparently the fido consortium didn't want keys to be exportable.

But I'll try it again, good point. I think with paypal the issue was also that they refuse passkeys in firefox and I don't use chrome so I was stuck there too. With Amazon it tried to enroll me but I got a bunch of errors.

Re: Things I learnt about passkeys when building passkeybot

#64

Post by otterley »

AlotOfReading wrote: post #54
stavros wrote: post #40

Earlier quoted context omitted.

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.

If you trust that the cryptography employed in passkeys is effectively unbreakable, then it follows that for all intents and purposes, passkeys cannot be phished. It’s the same thing as trusting that your browsing sessions cannot be MITMed because the end to end encryption is sufficiently strong.

Re: Things I learnt about passkeys when building passkeybot

#65

Post by [deleted] »

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…

[deleted]

Re: Things I learnt about passkeys when building passkeybot

#66

Post by otterley »

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?

Re: Things I learnt about passkeys when building passkeybot

#67

Post by sigmar »

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…

Both things can be true:

1) that they're enforcing these specs for technical reasons, not because they want vendor lock-in

2) a result of these decisions in the long term is vendor lock-in

Re: Things I learnt about passkeys when building passkeybot

#68

Post by [deleted] »

ajross wrote: post #16
xg15 wrote: post #8

> generateKey is a JS API that allows you to create new key pairs, where the private key cannot be extracted similar to passkeys. Is that "cannot be extracted" from JS only, or is this an actual device-locked, TPM/SEP-bound key like passkeys? If it is, it seems kind of like the buried lede to me that there is a browser API that lets any website built its own completely unstandardized quasi-passkey system and lock the…

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…

[deleted]

Re: Things I learnt about passkeys when building passkeybot

#69

Post by godelski »

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.

That's one way to read but I think a narrow way. Besides, my issue wasn't actually an issue with security now was it?

In practice we don't actually want the best security though. We frequently make concessions. I mean with my bank I don't want "the best" security. If I lose my credentials I don't want to go broke. If my credentials get hacked (especially if hacked by no fault of my own!) I want that money recovered. These things would not be possible with "the best" security.

In fact, in a different interpretation I would call those paths less secure. Ability to recover is a security feature just as much as it's not.

Both security and privacy do not have unique all encompassing solutions. They are dependent upon the threat model.

Importantly when designing things you have to understand modes of failure. When you design a bridge you design it to fail in certain ways because when/if it fails you want it to do so in the safest possible way. Why does this pattern of thinking not also apply here? It seems just as critical here! In physical security you also have to design things for both fail open and fail closed. You don't want you always fail close, doing so gets people killed! So why is the thinking different in software?

Not to mention:

How do I login from my Linux machine if I'm only using my iCloud key?

Your logic would lock me into the apple ecosystem forever and that's a worse security setting than anything else we discussed. Apple decides to become evil and I'm just fucked. Or swap Apple with Microsoft who is actively demonstrating that transition

Re: Things I learnt about passkeys when building passkeybot

#70

Post by quantummagic »

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.

I've never had to upload my government ID to any site; and none of my family have either. It's beyond naive to think that enshrining such a protocol won't lead to more widespread adoption, and even legislation requiring it. It's infrastructure that is quietly being built first, and enthusiastic authoritarian governments will eagerly embrace it.
Post reply on HN