It should have never been a cloud password manager play. It should be hardware device only, and tied to the device. One passkey on each hardware device.

▲

jallmann 2 days ago | parent | next [-]

That leads to the cross-device usability issues from the original post. Even for an experienced engineer, it's a headache to manage multiple devices across multiple sites.

With the "cloud password manager" angle there is some hope of being user friendly, although we're certainly not there yet for most folks.

▲

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

Then most of us would never use it. That means either:

- Only one specific device can ever login (bad).

- It doesn't limit login to one specific device, therefore it does nothing.

Linking Passkeys to a physical device was always DoA. At least not without a way to enroll every device you own, and strong recovery strategies. But considering how inconsistent every company's Passkey implementation is (inc. many that only allow ONE TOTAL!), it is DoA.

▲

thewebguyd 2 days ago | parent | next [-]

> Only one specific device can ever login

That's entirely service dependent, and the standard doesn't mandate "Service must not allow multiple passkeys"

> It doesn't limit login to one specific device, therefore it does nothing.

It's not nothing. It provides an attestation that you the user are in physical possession of the device, and have passed the challenge to release the key form the TPM (biometrics, pin, something like a yubikey).

Giving your private key to a cloud password vault makes it phishable again (via an attacker getting acsess to your vault, just like with passwords). The private keys are supposed to be non-exportable, and the cloud password managers defeat that as well.

	▲	sib 2 days ago \| parent \| next [-]
		>> Only one specific device can ever login > That's entirely service dependent, and the standard doesn't mandate "Service must not allow multiple passkeys" Unfortunately, given the laziness, incompetence, and cost-consciousness of organizations like traditional financial institutions, telcos, governments, etc., many of them have & will end up with that implementation.
	▲	tialaramex 2 days ago \| parent \| prev [-]
		> That's entirely service dependent, and the standard doesn't mandate "Service must not allow multiple passkeys" In fact WebAuthn is explicit that you should allow multiple tokens. But every time I see an HN thread it has people who insist this doesn't work or at least isn't common. When asked for examples, if they give any answers... 1. Most often these are sites where you can't use this technology at all. They'll have TOTP or something and apparently "I don't know anything about this" == "I know everything there is to know about this topic" in the increasingly LLM-crazy world we inhabit. 2. Usually otherwise it's AWS. Which is pretty annoying, but it's one site. I have like a couple of dozen places where I use WebAuthn and in all of those two (or three, or in a few cases four) tokens are enrolled. I don't have an AWS account, my employer is a Microsoft-only shop in this respect.

▲

pishpash 2 days ago | parent | prev [-]

Why? The "one device" can be something portable like a Yubikey-like USB key, or for that matter, a smart phone, because people are already forced to use phones to do authentication codes, so it is kind of assumed a phone is always with you. In fact there is an existing workflow for this, where you use the phone to scan a QR code and pass the challenge back.

▲

Zak 2 days ago | parent | prev [-]

Then I wouldn't use it, and I would probably stop using services that tried to push me in to it.

I use multiple devices and I want to log in to things using only my master password. I also want to be able to back up my credentials to local encrypted storage so I can restore them if my password manager service provider stops operating or becomes untenable.