Passkeys do marginally improve security against MITM and phishing attacks, but they are primarily for protecting the lowest common denominator from themselves: people who re-use passwords and/or don't use a password manager.
If you use multiple devices throughout the day, registering passkeys in all of these systems becomes a big headache with O(m*n) complexity, so putting the passkeys in a password manager is the only realistic solution. But this still breaks the login flow for a very common use case: how do I log in on a device that I don't own? With a password in a password manager I at least have the option of manually typing the password.
The biggest problem, though, is how users are pushed into it without any warning or knowledge of what they're signing up for. I've accidentally set up passkeys just by clicking an okay button a few times in the past and had to go back and figure out how to undo it after being blocked from login on another computer (which computer was I on again?).
> But this still breaks the login flow for a very common use case: how do I log in on a device that I don't own? With a password in a password manager I at least have the option of manually typing the password.
This is meant to be solved by the cross-device flow - a QR code pops up that you scan, and a secure channel is established from that with your other device.
[Disclosure: an editor of said standard]
> The biggest problem, though, is how users are pushed into it without any warning or knowledge of what they're signing up for.
On macOS/iOS, the system gives this prompt regardless of where your passkeys are being created/stored:
Save a passkey?
"<site>" supports passkeys, a stronger alternative to passwords that cannot be leaked or stolen. A passkey for "<username>" will be saved in "<provider>".
There is a transparent upgrade option though that sites can request - basically when a site supports passwords and passkeys, they can request a password manager supporting both create and return a new passkey on password sign-in.
> [...] and had to go back and figure out how to undo it after being blocked from login on another computer (which computer was I on again?).
That's unfortunate. A site/service should absolutely not replace other passkeys, nor should it remove other sign-in options like passwords, without explicit user consent.
The above credential upgrade flow makes that doubly so; even if someone relies on a password manager to manage and provide their credentials for a site, it very well may not be the singular piece of software that does so.
> This is meant to be solved by the cross-device flow - a QR code pops up that you scan, and a secure channel is established from that with your other device.
That only works if the device has working camera and bluetooth. What if I want to log in from my new desktop PC to an account whose Passkey is stored on my old desktop PC?
drtz · · focus · HN ↗
If you use multiple devices throughout the day, registering passkeys in all of these systems becomes a big headache with O(m*n) complexity, so putting the passkeys in a password manager is the only realistic solution. But this still breaks the login flow for a very common use case: how do I log in on a device that I don't own? With a password in a password manager I at least have the option of manually typing the password.
The biggest problem, though, is how users are pushed into it without any warning or knowledge of what they're signing up for. I've accidentally set up passkeys just by clicking an okay button a few times in the past and had to go back and figure out how to undo it after being blocked from login on another computer (which computer was I on again?).
dwaite · · focus · HN ↗
This is meant to be solved by the cross-device flow - a QR code pops up that you scan, and a secure channel is established from that with your other device.
[Disclosure: an editor of said standard]
> The biggest problem, though, is how users are pushed into it without any warning or knowledge of what they're signing up for.
On macOS/iOS, the system gives this prompt regardless of where your passkeys are being created/stored:
Save a passkey?
"<site>" supports passkeys, a stronger alternative to passwords that cannot be leaked or stolen. A passkey for "<username>" will be saved in "<provider>".
There is a transparent upgrade option though that sites can request - basically when a site supports passwords and passkeys, they can request a password manager supporting both create and return a new passkey on password sign-in.
> [...] and had to go back and figure out how to undo it after being blocked from login on another computer (which computer was I on again?).
That's unfortunate. A site/service should absolutely not replace other passkeys, nor should it remove other sign-in options like passwords, without explicit user consent.
The above credential upgrade flow makes that doubly so; even if someone relies on a password manager to manage and provide their credentials for a site, it very well may not be the singular piece of software that does so.
raron · · focus · HN ↗
That only works if the device has working camera and bluetooth. What if I want to log in from my new desktop PC to an account whose Passkey is stored on my old desktop PC?