Live data from Hacker News

Passkeys: A shattered dream

fy.blackhats.net.au

441–450 of 789 posts

Re: Passkeys: A shattered dream

#441
post #358

Earlier quoted context omitted.

I use far more sites than I ssh into servers, which makes this much more of a pain. Like, every time I sign up to a site I need to grab all 5+ devices I might ever use and add them to every site, or I can't e.g. log into my D&D game while travelling because I forgot to generate a key on the work laptop? If all my devices are destroyed in a house fire again, I'm locked out of everything? These have been my big concern…

> every time I sign up to a site I need to grab all 5+ devices I might ever use and add them to every site, or I can't e.g. log into my D&D game while travelling because I forgot to generate a key on the work laptop? You don't need to log in to every app on every device the instant you register a new account. Just make a passkey on a couple of devices that you're likely to have around and you'll probably have what yo…

> No worries, I just tap my security token to my phone and I'm logged in.

What allows you to tap your token on your phone and register a passkey-stored-on-phone registered with TotallyCoolService? Did you previously set your phone and token to be "mutually trusted devices" in some way?

Or what's preventing a thief from tapping my token on their phone to register it on TotallyCoolService?

Re: Passkeys: A shattered dream

#442

Every time I see a long inscrutable discussion about Passkeys, I see a weird avoidance of the "something you know" part of security. Here in the US, courts and law enforcement have every right to get your username, fingerprint, retina scan, face ID, whatever. But they don't have the right to extract something from your brain. Unless I'm missing something basic (which at this point, I don't think is my fault since thi…

> But they don't have the right to extract something from your brain. Most folks store passwords in password managers and don't use their brains to retrieve them.

Which is a bad idea. Right? That counterpoint defends a bad idea. We should be against the practice of permanently-unlocked password managers, and password managers that are only locked by "something you have". People also create ssh keys with null passwords, but it's also a bad idea and we should be opposed to that.

Re: Passkeys: A shattered dream

#443
post #435
post #268

Earlier quoted context omitted.

This has always been my objection to them, as a user, as they have been presented. As an employee, I don't care. Businesses have sufficient relationships and mechanisms to self-serve any issues that come up, like lost keys. But as a user, I do not. It is a drop-dead requirement for me for any authentication material that I have some way of backing it up and modifying it in case of compromise. Besides, give the Silico…

I'm not quite sure if even the corporate case works properly with iOS & Android devices as the article states, otherwise you could become a 'corporation of one' and side step all of this stuff. Even the corporations look like they have to use apple or google's crap for employee devices and accounts?

I mean in principle. If I throw my authentication material into a lake, there's an IT department that can have authorization to re-establish it. If I throw my personal authentication material into a lake, there's really nobody who can help me. I can try to convince a large company that I'm really me, but that is indistinguishable to them from a social engineering attempt, and dealing with that is high touch and expensive. I need to be able to back up my stuff. If the aforementioned "large company" is the one holding my authentication material and anything whatsoever bobbles it, then I'm back to trying to convince them I'm me.

A "corporation of one" is still just me, so I'm not talking about trying to technically hack around things by pretending to be a corporation.

When you see it this way it becomes really clear that Google, as a corporation, is an absolutely atrociously awful company to be the ones holding the keys to my identity. But there aren't any good, big, easy, safe options. I need to be able to self-service. Or we need to create much smaller, more local (in some sense, not necessarily geographical) holders of the auth material that I can convince I am me and they can reset it if something goes wrong. But that gets into a complicated web-of-trust and that's never worked out.

Re: Passkeys: A shattered dream

#444
This feels overly cynical to me. The article is a bit rambly so let me try to distill the problems:

1. Most relying parties support resident keys only. This makes a bad user experience because users are surprised when they run out of space, and may have to wipe their device to get more.

2. Most authenticators do not allow you to export your keys. If a relying party only allows a single credential per account, this creates authenticator lock-in, which is a bad user experience.

3. Chrome is uncooperative about the Authenticator Selection Extension, and that can make a bad user experience if the relying party rejects the device attestation after enrollment.

Yes, these are all bad user experiences, but they don't indict the technology. It sounds to me like the relying party can mitigate all of these issues:

1. Support non-resident keys. Seems like it really doesn't have to be a bad user experience. Usernames are easy to remember. Just use their email address.

2. Support multiple keys per account. Most users will have multiple authenticators. Let them enroll several and they're not locked into any one in particular. Most users won't care about this, but for important services it's an option.

3. As a relying party with strict authenticator requirements, just explain those requirements on the passkey registration page. People can read. They don't have to be that confused when their unsupported key doesn't work.

I get that there's nothing users can do when the relying party creates a bad experience, but if a relying party has all the power to create a good experience, is it really worth being this gloomy about the technology?

Re: Passkeys: A shattered dream

#445

Earlier quoted context omitted.

It didn't have to be this way, but the hype train won over practical considerations: https://fy.blackhats.net.au/blog/2023-02-02-how-hype-will-tu...

Why couldn't a non-resident security key send it's public key as username? And the response contains the actual username and private key.

Because the security key doesn't store any public keys.

Basically, the security key stores a single symmetric key. It'll generate a public/private keypair on registration, encrypt it, and send it to the server. On authentication the server will return the keypair back to the security key, which decrypts it and uses the retrieved private key for authentication.

Re: Passkeys: A shattered dream

#447
post #419

Earlier quoted context omitted.

I’m in the same place. I feel like most of the replies to your comment talk about the technical aspect of it. What’s stopping me is that I don’t have a mental model of the management of the passkeys for the whole lifecycle of my account. Can I use it cross platform? Can I allow someone else to use the same account? What happens if I lose or don’t have access to my phone or laptop? What if I die, can my spouse log in…

> I feel more at risk of losing access to my accounts if I were to switch to passkeys, because I don’t fully grasp their long term lifecycle. It's my understanding that you can't switch password managers without generating a new passkey for each individual service you use (I'm not an expert here, so someone feel free to correct me). That's already enough for me to not switch.

That’s my problem with TOTP second factor authentication. I’ve used Authy for years because it works on Windows and mobile, but now they’ve decided they aren’t going to work on Windows anymore (but they still force update a perfectly working Windows app and there’s no way to opt out). I have no way to export my 30+ TOTP accounts to a new system. I often don’t want to have my phone around when I’m trying to focus and get work done, but now I have no choice. It’s infuriating. Is there any cross-platform TOTP system that has the ability to export your keys? Is that even a thing that’s technically feasible?

Re: Passkeys: A shattered dream

#448
post #196

Earlier quoted context omitted.

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!

You could use YubiKey to unlock Bitwarden that can practically store unlimited keys

Yes, but that provides a significantly less secure experience. All the important cryptographic operations are done in a regular computer program rather than in a HSM, at that point why bother with the Yubikey at all?

Re: Passkeys: A shattered dream

#449
post #444

This feels overly cynical to me. The article is a bit rambly so let me try to distill the problems: 1. Most relying parties support resident keys only. This makes a bad user experience because users are surprised when they run out of space, and may have to wipe their device to get more. 2. Most authenticators do not allow you to export your keys. If a relying party only allows a single credential per account, this cr…

If the underlying technology is poorly specified and confusing enough that it doesn’t get implemented well in 95% of cases, then yes, that does indict the technology. See also: PGP and email encryption in general.

But even if on balance the tech is worth implementing, it’s clearly not easy and your suggestions to “just” do several things that aren’t happening ring a little hollow.

Re: Passkeys: A shattered dream

#450

Earlier quoted context omitted.

So passkeys are essentially like SSH keys but for web/app logins

... with some of the functionality of SSH keys removed, like being able to use one key for many accounts, or many keys (on many machines) all for the same account. At least that's how I understand it.

I think you're right about the first part...a passkey being tied to a single account on a single site.

But not the second: on Github for example you can have multiple passkeys for the same account.

Post reply on HN