[kijin]

Password managers are phishing resistant. The browser plugin will not offer to autocomplete passwords on an identical-looking punycode domain.

A sufficiently long, randomly generated password is also database-leak resistant. Good luck brute-forcing a 128-bit random string, hashed with scrypt or whatever.

So the only significant advantage is replay resistance. Which might or might not be a big deal, but let's not overplay the advantages.

[nmjenkins]

> Password managers are phishing resistant. The browser plugin will not offer to autocomplete passwords on an identical-looking punycode domain.

True … but the reaction to this by the vast majority of users is to go "stupid password manager autofill not working again", and copy and paste their password out of the pw manager and paste it straight into the phishing site…

[vladvasiliu]

Well, IME this tends to happen on "let's be super secure and disable or otherwise break the login fields" sites, so I'm not sure these people will bother implementing actually useful security measures.

[aaomidi]

Passkeys means no secret material traverses the web.

This is a huge benefit. There’s no other way to put it.

From the admin side this also means significantly simpler database design

[resfirestar]

The phishing resistance isn't that straightforward in practice. It requires using browser extensions, which some people avoid for understandable reasons (poor security track record compared to everything else about password managers, and some of them just aren't very good). Many services use multiple domains (my bank has a .com, a .org, and several third-party vendor domains where you might be expected to enter your credentials), so many people who don't know how to update their password manager entries are probably in the habit of manually copying info into places where it doesn't autofill. And speaking of places where it doesn't autofill, the vast majority of mobile app developers seem to be unaware of things like autofill hints for login fields and apple-app-site-association.

[beagle3]

The “database leak” argument is wider, though. It applies to password reuse (or systematic generation) and a leak from another site - which, may be stored in plaintext, or otherwise has a compromised login procedure that leaks passwords regardless of how it’s stored for validation.

You could say - and rightly so - that a person who reuses passwords invited whatever pwnage they get. But these people walk among us, do not use a password manager (often because not tech savvy enough), and passkeys are usable for those people.

[theshrike79]

Are password managers resistant to social engineering? You can copy & paste a password to a "support chat" from the manager. You can't do that with a passkey.

The password is only resistant if the one storing it is following best practices, which are NOT enforced and you really can't check for from the outside.

[kijin]

Well if we're talking about social engineering, I don't think it will be difficult to convince the support guy at most companies to disable passkeys on the target account altogether. :(

[theshrike79]

If you can engineer "the support guy" then you can do a lot more than disable one passkey.

I'm talking about engineering on the other side, the person who has the password and uses it to log in. You can't social engineer Miriam from Accounting to give their passkey, you can do it with a password.