Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Passkeys: A shattered dream

fy.blackhats.net.au

Post reply on HN
Print view View original

191–200 of 789 posts

Re: Passkeys: A shattered dream

#191

Post by brabel »

bradley13 wrote: post #124
tux3 wrote: post #94

Earlier quoted context omitted.

"Exactly" is under a lot of strain here. SSH is nice because you don't have to think about it. Your private key sits in your .ssh folder, and then everything is transparent. You _can_ put an SSH key in a smartcard if you want, but you have to opt-in to this kind of pain. And even if you do, almost all SSH servers will support that login method without issue. Passkeys don't sit in your .passkey folder. Your browser do…

Passkeys ought to be exactly like SSH keys. Unfortunately, they are not. The attempts to restrict when and how they are stored, and how you can access them - those are going to cause a lot of pain and confusion. I have all of my SSH keys stored in KeepassXC, which (imho) is a lot more secure than having them hang around in my .ssh directory. Open KeepassXC, and the keys are available. Close it, and they're gone. Sync…

They shouldn't be exactly like SSH keys. With SSH keys, you can go and copy/paste your private keys on a scammer's website because they asked you nicely. People will totally do it as they don't understand what they're doing. The main thing with passkeys, and key dongles in general, is that you simply can't do that as the keys are inaccessible and you can only prove possession of a key when asked by a domain you've explicitly registered with (the proof-of-possession is never sent to any other domain than that which you registered with). What OP says is that opens the possibility for key providers to lock-in users, as that seems like an unavoidable side-effect of the legitimate goal of preventing phishing (phishing is the biggest security issue today, to increase security means making phishing impossible, so I still support passkeys as the best solution for that).

Re: Passkeys: A shattered dream

#192

Post by hal0x2328 »

masklinn wrote: post #171
javawizard wrote: post #143

Earlier quoted context omitted.

The risk of your password getting stolen in between your browser and whatever hash algorithm the service you're authenticating with puts your password through before storing/verifying it. That's the benefit you get from passkeys that no password manager will otherwise be able to give you.

If your TLS connection has been MITM’d, you have much bigger problems than your unique randomly generated password being sniffed out.

It's very easy to fall prey to an Evilginx or similar AITM phishing attack. Passkeys or TLS client certificates are the only guaranteed defense. Relying on the user noticing the different domain or the lack of autofill by the password manager, not so much.

Re: Passkeys: A shattered dream

#193

Post by tssva »

bitlevel wrote: post #154
kiwijamo wrote: post #121

Earlier quoted context omitted.

How do you sync it to your Windows PC? Is it native Apple-Microsoft sync or does it require e.g. installing an Apple application?

I would also like to know how this is achieved.

Apple’s iCloud for Windows includes an iCloud Password app which allows accessing and managing your keychain stored passwords on Windows. They also have a browser extension for Chrome and Edge which does autofilling in those browsers on Windows. I haven’t used them in a long time so I don’t know if they have added passkey support to them yet.

Re: Passkeys: A shattered dream

#194

Post by flup »

usrusr wrote: post #125
flup wrote: post #44

Earlier quoted context omitted.

One thing that comes to mind is with the earlier WebAuthn implementations in iOS, before they were stored in iCloud and called passkeys, there was no management interface for stored passkeys and 'clear website data' (to delete cookies etc.) would actually erase all credentials permanently. It was useless this way.

Why useless? Not an authentication scheme to and all other authentication schemes, but certainly a (much) better successor to the login cookie?

I do not mean passkeys in general but early iOS implementation was useless since it deleted passkeys along with your cookies and other website data. The passkey iOS implementation is useful in its current form.

Re: Passkeys: A shattered dream

#195

Post by jve »

triblemaster wrote: post #184
joshstrange wrote: post #134

I’ve avoided passkeys so far because I just don’t have a good mental model of them. All my passwords are randomly generate and stored in a password manager so I really haven’t felt the need to switch or felt constrained by my existing set up. I fully understand username/email + password and remembering the pain of things like “app specific passwords” makes me worry that some tools (open source, cli, etc) might not in…

The mental model is very simple. If you use things like Yubikey, it is exactly like a key you use to start your car. A single password protected key maybe. In essence, it is your password manager but something that everyone can use. And something that doesn't need to be on the cloud.

Well that doesn't help understand: How passkeys can be backed up? Where/how they are stored? What if I loose my phone, computer? How can I login to some app using pc/mobile?

I haven't been into passkeys as you see, but some easy login like that leaves me with a lot of questions.

Re: Passkeys: A shattered dream

#196

Post by crote »

triblemaster wrote: post #182
saagarjha wrote: post #21

The biggest issue with passkeys is that I just can't trust the companies offering them. They are locked into the platform for reasons that are ostensibly security but often indistinguishable from platform lock-in. If you make a passkey on an Apple device as far as I can tell it will never leave that device, ever, and there is no way to change this. Of course this means you can never be phished for your credentials bu…

You can always use passkeys like Yubikey or others which are much more multi-platform.

This isn't a viable option in practice, because Passkeys use "Resident Keys". This means the credential needs to be stored on the Yubikey - which has a limited number of key slots. Need to log in to more than 25 (I believe) websites? Tough luck!

Re: Passkeys: A shattered dream

#197

Post by whywhywhywhy »

saagarjha wrote: post #21

The biggest issue with passkeys is that I just can't trust the companies offering them. They are locked into the platform for reasons that are ostensibly security but often indistinguishable from platform lock-in. If you make a passkey on an Apple device as far as I can tell it will never leave that device, ever, and there is no way to change this. Of course this means you can never be phished for your credentials bu…

The platform lock in attempt is wild, my initial experiences with Passkeys were great on iOS and Safari, either getting pushed to touch-id or scanning a QR with my phone. But then in Chrome I couldn't get into GitHub because chrome would only push me to use their manager and wouldn't offer a QR code.

Seeing this more and more with Chrome, like Credit Card numbers used to just save and autocomplete in browser but then they had some popup that was worded in a weird way that tricked me into saying it into Google Pay. Then I had to like type in the CCV to retrieve the card but then it also charged my bank account 1c for the privilege of autocompleting the card each time. Took me good 20 minutes to delete my card, get it saved back in the free local auto completely and shut down my Google Pay account I never knew I had.

Re: Passkeys: A shattered dream

#198

Post by joshstrange »

xoa wrote: post #185
joshstrange wrote: post #134

I’ve avoided passkeys so far because I just don’t have a good mental model of them. All my passwords are randomly generate and stored in a password manager so I really haven’t felt the need to switch or felt constrained by my existing set up. I fully understand username/email + password and remembering the pain of things like “app specific passwords” makes me worry that some tools (open source, cli, etc) might not in…

> All my passwords are randomly generate and stored in a password manager so I really haven’t felt the need to switch or felt constrained by my existing set up. The basic logic here is pretty clear imo. Passwords are still symmetric factors, and they're also completely unstandardized. So you still have to do a significant amount of manual management crap that should not exist, deal with UI that should not exist, and…

Thank you for that description. I do understand at a high level that it’s similar to SSH keys with the pub/private aspect.

I think I really need to implement it myself at least once to really grasp it. Maybe that’s stupid/slow of me but that’s how I learn best.

Re: Passkeys: A shattered dream

#199

Post by bonton89 »

JoBrad wrote: post #180
sevanteri wrote: post #26

Earlier quoted context omitted.

This is why services need to support multiple passkeys per user just like they should support multiple 2FA methods...

The services that I use passkeys for (MS, AWS) do. I have separate passkeys for 2 browsers and on my phone.

The trouble is if it is on the service to do the support, they can revoke support at any time. They could use start tightening the screws on device attestation tomorrow for business reasons and drop support for your browser or phone.

Re: Passkeys: A shattered dream

#200

Post by Twisell »

xoa wrote: post #185
joshstrange wrote: post #134

I’ve avoided passkeys so far because I just don’t have a good mental model of them. All my passwords are randomly generate and stored in a password manager so I really haven’t felt the need to switch or felt constrained by my existing set up. I fully understand username/email + password and remembering the pain of things like “app specific passwords” makes me worry that some tools (open source, cli, etc) might not in…

> All my passwords are randomly generate and stored in a password manager so I really haven’t felt the need to switch or felt constrained by my existing set up. The basic logic here is pretty clear imo. Passwords are still symmetric factors, and they're also completely unstandardized. So you still have to do a significant amount of manual management crap that should not exist, deal with UI that should not exist, and…

Yes but what I'm still confused about is that: 1) Is one/some of your public key reused on different services 2) Or is there a different public key for each service

1) In the first case what will prevent different services to track users by comparing public key... and if so I would be more at ease with a site specific randomly generated password

2) In the second case when one service is breached you'd still have to manage rotation of public key somehow, how trivially is that done with current implementation ?

Post reply on HN