I get your problem, i don't really accept it as valid. Passkeys were always supposed to be fungible. You have one in your iPhone, a different one on your desktop. A third in your significant other's phone. All stored in the hardware tpm equivalent.

You can have 7 passkeys. You can have 14.

The real failure of passkeys (emphasis on the s!) is that people think they must only have one.

▲

raron 2 days ago | parent | next [-]

I don't think that would work either.

Let's say I have a new account and a single Passkey in the TPM of PC1. I want to log in from PC2, too. How can I do that? (I know there is some trickery with Bluetooth, but I haven't seen anything supporting it, and desktop PCs usually doesn't have Bluetooth connectivity.)

AFAIK some browsers can do some magic to use a Passkey from your smartphone on a PC, but you need to log in to the same browser-sync account from both device (which brings back us to the same issue).

Also the whole thing becomes a mess when you change devices. You need to log into all the services you have ever used to delete the Passkeys from devices you no longer have, and you need to add a new passkey from a new device you bought to all the services you use.

▲

TheBicPen 2 days ago | parent | next [-]

Can these services not use the same fallback mechanism that already exists for non-passkey logins? i.e. an email with a 1-time code or similar. Yes that somewhat defeats the purpose of passkeys but that option is going to exist for a long time regardless of passkey adoption.

If you don't want to downgrade security, how about requiring confirmation from another session that is already logged in using a passkey? e.g. You try to log in on PC2. A prompt appears with something like "confirm this login from [PC1, etc.]". You log in on PC1 using your passkey. The service recognizes that the login id definitely you, or at least someone in possession of your physical device and login method for that device. Therefore, it then allows PC2 to register a new passkey. Kinda similar to how google confirms new logins by sending a notification to your phone.

	▲	raron 2 days ago \| parent [-]
		That could work, but then the service needs to implement complex non standardized authentication mechanism outside of Passkeys. You will have 14 different services with 15 different options. I don't think that's really user-friendly. Also it could be vulnerable to MFA fatigue attack, if people would constantly get new "confirm this login" popups, they would press anything to make it go away. So you would need something that is explicitly initialized from a trusted session, then you need something to connect the trusted session to the new login. If you want that to be user friendly you need some short codes and can't rely on QR code / Bluetooth, or two-way interaction. And that brings up the phishing / MitM attacks again.

▲

halJordan 2 days ago | parent | prev [-]

You generate another passkey is your answer. How do you do that? The exact same way you do today. Why would you need to delete invalid passkeys? You wouldn't.

▲

raron 2 days ago | parent [-]

> You generate another passkey is your answer. How do you do that? The exact same way you do today.

How can I do that, if Passkeys are the only option to log in?

If I can just use a password to log into a website without Passkeys, then Passkey is useless and doesn't add any security benefit.

> Why would you need to delete invalid passkeys? You wouldn't.

I sell my old (and no longer updated) phone or PC and don't want someone to get access to my account by getting access to the secret keys.

An non-revocable authentication mechanism is just stupid.

▲

winstonwinston 2 days ago | parent [-]

> How can I do that, if Passkeys are the only option to log in?

It is not feasible to remove password login or some other recovery login method.

> If I can just use a password to log into a website without Passkeys, then Passkey is useless and doesn't add any security benefit.

It isn’t useless, point is you don’t get to type in your password on a device that has passkey generated already, or get phished on a fake web address for example.

> I sell my old (and no longer updated) phone or PC and don't want someone to get access to my account by getting access to the secret keys.

Passkeys are meant to be protected by either PIN or biometrics, however they are also meant to be revocable on the web, at least they are for services i’ve been using with passkeys.

▲

raron 2 days ago | parent [-]

> It is not feasible to remove password login or some other recovery login method.

Then passkeys doesn't provide any real value if you have other less secure recovery option.

Let's say I have a bank account, going to the branch and doing an in person ID check is a valid recovery option, but nobody would want to do that just to log in from a new device.

> It isn’t useless, point is you don’t get to type in your password on a device that has passkey generated already, or get phished on a fake web address for example.

That's solved by letting the browser to remember the passwords.

> Passkeys are meant to be protected by either PIN or biometrics, however they are also meant to be revocable on the web, at least they are for services i’ve been using with passkeys.

PIN and biometrics doesn't have any inherent security. They rely on some hardware (or software separated from main system) feature, and even those can have vulnerabilities.

▲

winstonwinston 2 days ago | parent [-]

Using strong password as you suggested is a solved problem for your use case, but that is not universal. Passkeys provide universal security for all.

Also PIN or biometrics verification to access passkey from device bound TPM or security enclave solved the problem you implied might happen, such as losing your device. How do you protect your password manager, if any?

> even those can have vulnerabilities.

We shouldn’t just give up because everything is inherently insecure.

	▲	raron 2 days ago \| parent [-]
		> We shouldn’t just give up because everything is inherently insecure. True, but no sane way to mass revoke Passkeys from stolen / lost device is just bad design.

▲

chrisandchris 2 days ago | parent | prev | next [-]

> [...] people think they must only have one.

That's the real failure? I think the real failure is that people must have _more than one_. I thought so hard to add all my credentials to 1Password. Now people tell me I should use a Yubikey (or better two or three of them). What do you think, I'm going to register a couple of hundred accounts times three for something I already have (my password manager)?

The real advante in passkeys is in allowing me to log in into a service on a foreign device without typing [my password], which is (honestly) something now sane person should ever do.

	▲	halJordan 2 days ago \| parent [-]
		Again, I'm attracting people who fundamentally fail to grok passkeys . That's cool, but doesn't entitle you to anything

▲

tsimionescu 2 days ago | parent | prev [-]

Again, is this true for all major sites that support passkeys? And how do you set it up? My passwords are automatically synced between my devices, how to I achieve the same thing if I set up an account with a passkey?

▲

halJordan 2 days ago | parent [-]

Why would you take one passkey and move it between devices? Generate a new one. They're fungible. You set it ask to the exact same way you do today. It's not a problem.

	▲	tsimionescu 2 days ago \| parent \| next [-]
		Again, do all major sites allow you to register 6-10 passkeys? Not asking if they could in principle, but do they in practice do it? And how easy is it to log in with a new device to generate that passkey? Do I have to jump through hoops on my laptop, second phone, secondary browser, and so on? Finally, if it is easy to register a new device, how does the anti-phishing still work? Can't an attacker just convince me to use whatever means I would normally use to register a new device, instead of an existing secure passkey?
	▲	pibaker 2 days ago \| parent \| prev [-]
		This assumes all services let you generate new passkeys with no hassle, which is not true.