The offer a strong protection against phishing attacks that would still get plenty of password manager users: fake websites. A passkey is strongly linked to a domain, so a fake site can't get that credential.

Some password managers will only fill if a domain matches, but IRL the response I've seen from most users when it doesn't match is to assume the integration broke and manually copy/paste it in. I've also seen lots of them do stuff like happily autofill on any prefix of the domain, so your credential for `something.example.com` will autofill into `fake-something.example.com`.

▲

ealready_value 4 hours ago | parent | next [-]

"Oh, usually my bank just logs me in, that's strange. Let me just go grab my username and password and type it into this site that looks like my bank."

Same thing is going to happen with passkeys for non-technical users for exactly the same reason you stated. People will think the integration is busted and manually copy/paste the non-passkey credentials in. In that way, I would argue that passkey is not stronger protection against phishing attacks unless its the only way to login. It is, at best, a convenience for users.

▲

Latty 4 hours ago | parent | next [-]

If the user just has a username/password fallback and that's it, then yes, but the aim of passkeys is that won't be the norm, rather users will only have passkeys and the fallback would be to, e.g: magic link email log in where the phishing attack is still broken. I've seen some sites explicitly disallow plain username/password login after you enable passkeys for this reason (you can still put them in, but then it just does a magic link flow afterwards as a second factor).

▲

pamcake 4 hours ago | parent | prev [-]

The pitch is that passwords will supposedly be phased out entirely as an option.

	▲	cpburns2009 3 hours ago \| parent \| next [-]
		I've been told by multiple people that the recovery method of passkeys is to enter your username/password. If passwords are eliminated, your final recourse is fucked.
	▲	rcxdude 3 hours ago \| parent \| prev [-]
		Which is a laudible goal, but something that makes "oh just fall back to the standard insecure recovery process" not a very good response to the concerns about users being able to actually hold on to their passkeys easily and reliably.

▲

flerchin 4 hours ago | parent | prev | next [-]

How did fake-something get injected as a subdomain?

▲

Asmod4n 4 hours ago | parent [-]

Loads of hosting sites do this, username.domain.tld is the most common one.

	▲	somehnguy 4 hours ago \| parent [-]
		I guess it's a good thing my bank doesn't have a free web hosting service

▲

embedding-shape 4 hours ago | parent | prev | next [-]

> but IRL the response I've seen from most users when it doesn't match is to assume the integration broke and manually copy/paste it in.

I've seen people do this AFK as well, and I'm always helpfully suggesting them the correct way of solving this: verifying the URL again, and if correct, add it to the password manager so it remembers in the future, and never copy-paste passwords on the web. Basically 50/50 if they take the advice or come back after a week asking if it's safe to copy-paste the password into the website, and I try to inform again.

Shockingly, I saw one developer peer copy-pasting a password into a website, but I guess for these people there is no hope.

	▲	mos_basik 24 minutes ago \| parent \| next [-]
		Your last sentence got me good, as I'm a developer who copy-pastes passwords into websites (from a 12? year old KeePass database, for whatever that's worth). I've tried using the Firefox integration in the past - more than once - and I don't know... it had so many warts that I got fed up with it and turned it off. And now I have 1Password (from work) also doing its best to feed me credentials all the time. So trying the KeePass integration again is going to have them both drawing suggestion dropdowns all the time.. But ok, I'll give it another honest shot. Because of your comment.
	▲	Telaneo an hour ago \| parent \| prev \| next [-]
		There are too many websites where this is broken for me (even with Firefox's built-in password fill) to go as far as to never copy-paste passwords. If web devs actually implemented it consistently, I might be that draconian about it, but asking them to do that when we already have the '200 MB of JS is needed to view this page' problem, I have my doubts we're going to see this problem going away any time soon.
	▲	Latty 4 hours ago \| parent \| prev [-]
		It should be a big red flag for sure, but the reality is most users aren't going to understand that. They got told to use a password manager by someone or find it convenient, but they don't understand the security flow enough to catch that it's a potential attack, or how to resolve it safely. Historically I've seen lots of sites do a subdomain shuffle for login pages every now and then which routinely breaks domain matching, introducing false positives that users have to deal with, making them numb to the threat too. Passkeys baking in the domain check with no workaround means that sites can't do that, which is a benefit.

▲

lapcat 4 hours ago | parent | prev [-]

> Some password managers will only fill if a domain matches, but IRL the response I've seen from most users when it doesn't match is to assume the integration broke and manually copy/paste it in. I've also seen lots of them do stuff like happily autofill on any prefix of the domain, so your credential for `something.example.com` will autofill into `fake-something.example.com`.

Why would you trust the very same password managers that don't handle passwords properly to handle passkeys properly?

▲

Latty 4 hours ago | parent | next [-]

You don't. The browser handles the passkey matching to the domain which is obviously a better place to do it. There could obviously still be bugs as with all things, but it's much more intentionally integrated into the flow which makes it much harder to bypass.

▲

lapcat 4 hours ago | parent [-]

> The browser handles the passkey matching to the domain which is obviously a better place to do it.

I'm not sure why you're making a distinction. In many cases the browser is the password manager.

▲

Latty 4 hours ago | parent [-]

Right, I haven't seen that particular flaw in baked-into-the-browser ones (probably because they already having secure domain matching code ready to use), but the distinction is that doing the domain check is a part of the spec and standard, so e.g: sites aren't going to break it by changing the log-in subdomain routinely, as has been common historically.

Password managers have had to be permissive enough to work with most websites, and there is no standard for it. There have been sites that blocked the autofilling of passwords and so on as well.

My point wasn't this one particular flaw in some password managers is the reason to use passkeys (the copy/paste point is the much bigger issue anyway), just that it's an example of how relatively brittle the password manager process is. Having it a core part of the spec gives stronger guarantees.

▲

cruffle_duffle 3 hours ago | parent [-]

“There have been sites that blocked the autofilling of passwords and so on as well.”

Sites that do this irritate me so much. Ones that try to block pasting and stuff… like somebody intentionally baked that into the site. Who? And what was their rationale? Are they really so arrogant to think people are going to carefully type in some elaborate password not once but twice?

That and blocking paste in fields like bank account numbers and stuff.

Surely somebody here has been asked to implement these mis-features. Please explain what went through the heads of the people responsible for it?

	▲	pnw an hour ago \| parent [-]
		Blocking bank account numbers from being pasted is considered an error prevention measure. By forcing people to enter it manually at least once, you stop them from blindly pasting the wrong number twice. There's no real regulation requiring blocking paste but it has become an annoying informal standard of sorts.

▲

jkubicek 4 hours ago | parent | prev | next [-]

The users are the ones manually copy/pasting the password. There's no way the password manager could prevent this short of disallowing copying/viewing passwords.

▲

conradludgate 2 hours ago | parent | prev | next [-]

The password integration breaks because it's trying to detect password fields rather and failing because of weird HTML/JS code.

The passkey integration goes the other way, which is much more reliable.

▲

6P58r3MXJSLi 4 hours ago | parent | prev [-]

> Why would you trust the very same password managers that don't handle passwords properly to handle passkeys properly?

Gell-Mann amnesia effect

https://en.wikipedia.org/wiki/Michael_Crichton#%22Gell-Mann_...