Hacker News new | past | comments | ask | show | jobs | submit login

Isn’t tying specifically to a device and biometrics the point?



No. The point is replacing passwords with something which is equally user-friendly, but which cannot be phished.

Ie replacing passwords with cryptographic keys tied to a specific website.

That is, your passkey for amazon.com won’t work on a phishers site amozon.com or lookalike.somehost.org.

And in the hypothetical case of your passkey for site X being leaked it will never be the same as for site Y, so it’s not reusable.

No part of the specification requires Google, cloud or third party trust. Those are just “user-friendly” client-side implementations.


> which is equally user-friendly, but which cannot be phished.

This is good to bring up. Without vendor lock-in and attestation, passkeys have huge benefits for blocking phishing attacks. It's not "stick with passwords" or "deal with lock-in", it's possible to get rid of the current problems and still end up with a system that's way more secure than traditional passwords.


> No part of the specification requires Google, cloud or third party trust.

AFAIK the only reason you need Google, Apple, or etc. is because the mobile OS needs to make the process of doing the bluetooth pairing between a random device and the phone seamless. Given the crap networking we have in the world you need a 3rd party everyone can reach to exchange the most basic information. Then everything is local via Bluetooth.

> The point is replacing passwords with something which is equally user-friendly, but which cannot be phished.

Yes, and biometrics (which pretty much everyone uses) are great! They're device ONLY. It's entirely a convenience feature that avoids needing to enter the Required To Setup PIN/Passphrase every time.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: