Hacker News new | ask | show | jobs
by bryantwolf 106 days ago
The advantage is that the password never leave the device. It has a public key and signs challenges with the private key but nothing sensitive goes over the wire on every login
1 comments

It should be noted that that is not an inherential advantage of passkeys over passwords. It is possible to achieve the same with passwords, e.g. by using a hash-cascade.
Sure, but then you still need a protocol between user agent and website. If you just do this in Javascript, you're not protected against phishing sites just forwarding the password entered directly.

Passkeys can in fact be backed by exactly this, i.e. a HMAC-only stateless implementation backed by a single password: https://github.com/lxgr/brainchain

> Sure, but then you still need a protocol between user agent and website.

Yes of course. Just like you do for passkeys.

> Passkeys can in fact be backed by exactly this, i.e. a HMAC-only stateless implementation backed by a single password: https://github.com/lxgr/brainchain

No, not quite. It's written on there:

> "Login" with your passphrase, and you can create non-discoverable WebAuthN credentials (don't call them passkeys, but definitely be reminded of them) at ~all~ some websites supporting them (...)

That's the thing: with passwords, a website/app cannot prevent you from controlling the password yourself. With passkeys and attestation it can.

But attestation for passkeys is dead. Neither Apple's, nor Google's implementation (with negligible exceptions) support it anymore, so any site demanding attestation will immediately disqualify > 99% of all potential users.

Some still might, e.g. for corporate or high security contexts, but I don't think it'll become a mass-adopted thing if things don't somehow drastically change course.

It's still in the standard. They could remove it, but they don't, so from my perspective it's just like how Google wasn't evil. Until they decided otherwise.
> It's still in the standard.

Yes, because hardware authenticators (like Yubikeys) still commonly support it, and it makes sense there.

I guess they could add an explicit remark like "synchronized credentials must not support attestation", and given the amount of FUD this regularly seems to generate I'd appreciate that. But attestation semantics seem to be governed more by FIDO than the W3C, so putting that in the WebAuthN spec would be a bit awkward, I think.

is it fair to say all passkey implementations have this advantage while only some password implementations can match?
It is absolutely unfair to say it. Just like passwords stored in a password manager, passkeys can be copied out of the device for safekeeping. Because you can copy them out, a user can be induced to give them to someone.

I saw passkey boosters go very, very rapidly from "Passkeys are immune to phishing!" to "Passkeys are phishing resistant!" when lots of real-world people started using passkeys and demonstrated that you absolutely must have a way to back them up and move them around.

> passkeys can be copied out of the device for safekeeping

You can't copy them out on at least the iOS, Android, and (to my knowledge) Windows default implementations.

> lots of real-world people started using passkeys and demonstrated that you absolutely must have a way to back them up and move them around.

Millions of people use them without being able to move them around in the way you describe.

> You can't copy them out on at least the iOS, Android, and (to my knowledge) Windows default implementations.

Pardon? The official support docs disagree with you [0][1][2]. They absolutely leave the device.

Other passkey managers let them leave the device in a way that you control, but even the default ones copy them off the system they were created on.

[0] <https://support.google.com/accounts/answer/6197437?hl=en&co=...>

[1] <https://support.apple.com/guide/iphone/passwords-devices-iph...>

[2] Examine the "Can I use passkeys across multiple devices?" Q and its A here: <https://support.microsoft.com/en-us/windows/passkeys-frequen...>

Yes, they're synchronized, but I wouldn't call that "copying them out", as that to me implies somehow getting access to the raw private key or root secret bytes.

Both Apple and Google have pretty elaborate ceremonies for adding a new device to an existing account in a way that synchronizes over passkeys.

That qualifies as "immune to phishing" as far as I'm concerned. No reasonable person using a reasonable implementation will ever be successfully victimized in that manner.

We need to stop pretending that padded cells for the criminally incompetent are a desirable design target. If you are too stupid to realize that you are being taken for a ride when asked to go through a manual export process and fork over sensitive information (in this case your passkeys) to a third party then you have no business managing sensitive information to begin with. Such people should not have online accounts. We should not design technology to accommodate that level of incompetence.

If you can't stop driving your car into pedestrians in crosswalks you lose your license. If you can't stop handing over your bank account number to strangers who call you on the phone you lose all of your money. If you eat rotten food you get sick and possibly die. If you hop a fence and proceed to fall off of the cliff behind it you will most likely perish. To some extent the world inherently has sharp edges and we need to stop pretending that it doesn't because when we do that it makes the world a worse place.