Live data from Hacker News

Passkeys: A shattered dream

fy.blackhats.net.au

601–610 of 789 posts

Re: Passkeys: A shattered dream

#601

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…

People keep trying to answer this question, so I'll try, too, but I'm going to do a better job than anyone else. ;-) Passkeys are randomly generated passwords that are required to be managed by a password manager. All the major password managers support them, including Apple, Google, Microsoft, Mozilla, and 1Password. By requiring the passkey to be managed by a password manager, you get some anti-phishing protection.…

You can have multiple passkeys per username.

This is a huge difference from regular passwords, and the source of a lot of confusion about lock-in.

You can’t easily move a passkey out of the service managing it—true. But you should be able to easily add another passkey from another service. Then you deactivate the first passkey.

It’s a different mental model and the key is in the name. Passkeys are like keys. You can have more than one.

Re: Passkeys: A shattered dream

#602

Earlier quoted context omitted.

I use 1Password which supports Passkeys, and don’t have an issue across mobile or desktop. I don’t get what the issues people have really are. I never experience them (fortunately!).

1Password is a closed-source, cloud-hosted service. At any time, for any reason, they can close and delete your account, leaving you high and dry. Self-hosted, multi-device password managers are the only real solution. Thankfully, Vaultwarden and KeePassXC fill this role perfectly. Now if we could just get the other providers that require insecure email/SMS 2FA to follow suit, that would be great...

Your vault is stored locally on each device, so if they decide to shut down you just export locally, import somewhere else and move on. It’s not as big of a deal as you seem to be implying.

Re: Passkeys: A shattered dream

#603

Earlier quoted context omitted.

But what happens if I as an iPhone user want to switch to Android next year? Can I move my Apple passkeys?

No, you add a new passkey from Android and then remove the passkey from iPhone. 1. Login with the passkey from your iPhone. 2. In your account, add a new passkey from your new Android. Now both passkeys are active. 3. Login with your new Android passkey. 4. In your account, deactivate the passkey that is stored on your iPhone. Passkeys aren’t passwords. You can have more than one active at the same time. So instead o…

I have 400 accounts in my password manager.

There’s no way I’m doing that for each of them (or figuring out which ones support passkeys).

Re: Passkeys: A shattered dream

#604

Earlier quoted context omitted.

But what happens if I as an iPhone user want to switch to Android next year? Can I move my Apple passkeys?

No, you add a new passkey from Android and then remove the passkey from iPhone. 1. Login with the passkey from your iPhone. 2. In your account, add a new passkey from your new Android. Now both passkeys are active. 3. Login with your new Android passkey. 4. In your account, deactivate the passkey that is stored on your iPhone. Passkeys aren’t passwords. You can have more than one active at the same time. So instead o…

[deleted]

Re: Passkeys: A shattered dream

#605

Earlier quoted context omitted.

It happens to me very regularly that a password in my password manager is needed on a different domain. Maybe the logon process is at id.domain.com and password is pinned to domain.com, or maybe the password was created at signup.domain.com and so it doesn't pop up on domain.com, or you have to log in to a hotel's site with the password from their reward scheme (different domain), etc... In any case users are trained…

Also autofill is just broken by some sites and app login screens, so users are used to looking at and typing their passwords every now and then.

And, of course, the malicious site can arrange for autofill to be broken.

Re: Passkeys: A shattered dream

#606

Earlier quoted context omitted.

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

It is not required that your connection has been MITM'd. The service you are authenticating can accidentally log the plaintext password, they can store it with an insufficiently secure hash function or not salt it. A malicious browser extension can scrape it directly from the input form. Etc, etc, etc. Passwords are reasonably secure since we've been using them for a long time but there is in fact a huge chain of tru…

If the service is like that, then I'm not sure being able to log in as you is a major issue...

Re: Passkeys: A shattered dream

#607

Earlier quoted context omitted.

Why don’t you setup the Gmail account to forward? I know it’s a hassle, but will resolve the issue

That seems like an invitation for long-term pain if Google changes their policies, requiring someone to log in every X months or have their gmail account locked, for example, or some AI enforcement tool locks the account for inscrutable reasons.

I'm locked out of my Gmail and it still forwards to the recovery email address, but I can't get in to change the settings. They also won't allow me to download all my data, as required by statute, because I can't log in.

Re: Passkeys: A shattered dream

#608

Earlier quoted context omitted.

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

Unless I'm missing something these are nothing like SSH keys. They would be closer to regular password auth with SSH where you store the password in a file that's only readable by SSH. SSH keys are asymmetric such that I can make a public half available publicly and then use that to generate signatures of any challenge the server sends. With passkeys either the server needs to store the value raw(making it susceptibl…

I think you might be missing something.

https://fidoalliance.org/how-fido-works/

Re: Passkeys: A shattered dream

#609

Earlier quoted context omitted.

> "and use fingerprint/faceid instead of a password" This is the part that makes absolutely no sense to me. An essential aspect of passwords is that they can be changed. If someone manages to fake the digital representation of my fingerprints or face, what now? Security guru Bruce Schneier has written about this w/ much more eloquence and authority.

The unstated value of a USB key is the functional similarity to metal keys for ordinary people.

Not quite. It's easy to create a duplicate of your metal key, and many people do exactly that to avoid a situation where they lose it and have no way of opening their door. The fact that you can't do that with USB keys is my biggest gripe with them. I understand that inability to copy even if you have physical access to the original has its security advantages, but 1) most things don't actually need that much security, and 2) it could still be done by e.g. allowing you to buy them in premanufactured batches where all keys are identical.

Re: Passkeys: A shattered dream

#610

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…

A few weeks ago, I was unable to log in to Google on a new device with my 2FA token (Yubikey) because Google insisted on authenticating with a passkey/resident key, but the token had only been set up with non-resident TOTP or whatever it's called (and had been working properly in this mode for over a year). I was able to log in on another device and register the Yubikey with a passkey/resident key, but it was really…

It's a Google sign-in workflow problem. I've seen the same issue more than once - for whatever reason it decides that this one way of signing in is the one that you want to use right now, and it can be impossible to back out until some timeout kicks in.
Post reply on HN