[crazygringo]

I get that this is a theoretical vulnerability, but there's no way I'm turning off automatic autofill. It's way too convenient.

If some site has an XSS vulnerability, then they've already got access to my session cookies, and have the ability to spoof a "you've been logged out, please log back in" screen where people could type in a password anyways.

If a site is vulnerable to XSS it's basically game over security-wise. Asking browsers and password managers not to autofill feels more like security theater at that point.

That being said, the browsers and password managers that require the username and password fields to actually be genuinely visible to the user on top, non-transparent, in the viewport, are doing the right commonsense thing, and really that seems entirely good enough.

(Obviously if you're a political dissident or a target of suspected corporate espionage or something then you'll take greater security precautions like not using a password manager at all for certain accounts -- I'm just talking about normal users here.)

[Uberphallus]

> If a site is vulnerable to XSS it's basically game over security-wise. Asking browsers and password managers not to autofill feels more like security theater at that point.

Exactly. It doesn't matter if the manager inputs it for you or you input it yourself. The only case where I see it strictly worse is in pages that require an extra password input while already logged in for modifying sensitive info/settings.

[Diggsey]

Exactly. Plus, you don't even need to spoof anything - you can show the real login page!

There are many ways, but one particularly undetectable one would be to clear cookies and local-storage (causing the user to be logged out). Then use the history API to change the URL to the login page, and finally load the real login page in a full-screen iframe. Since the iframe contents are on the same domain, you can just reach in an extract the username & password fields as the user enters them.

[bakoo]

Bitwarden has a hotkey to invoke autofill on a page. Not sure how much safer it actually is, but at least it feels like I'm in control.

[shrimp_emoji]

It's safer as long as you don't hit it. (And, since the chance of you NOT hitting it is greater than zero, it can be called safer.)

Hit it when logging in to HN. It will populate both the set of fields you've highlighted (login) as well as the other set on the page (register). If there were a third, hidden, injected set of fields controlled by an attacker, those would be filled too.

The old security-convenience trade-off is an immutable law of the Universe.

[kaba0]

If an attacker could inject anything into the page, they may as well rewrite the form’s target URL, so I don’t see a real threat model for that.

[willis936]

>The old security-convenience trade-off is an immutable law of the Universe.

I'm not so sure. I type many fewer passwords now that I switched from reusing the same password for everything to using a password manager. I went from 60 bits of entropy to over 100 and when my single password got compromised it also compromised every account. Now I type a password once when I unlock a PC and use Face ID to unlock the database on my phone. On the whole things are much more convenient and secure. It was just very inconvenient to touch every account I own.

Rather than a hard and fast rule of the universe, the trade-off assumes a lot of things, such as users are trying to be secure with a specific range of effort.

[mackrevinack]

this wouldnt happen with keepass's auto-type which sends keystrokes from the desktop app. when you execute the hotkey with the focus on the username input, it types the username first, then sends the tab key, types the password, then sends enter. it wouldn't continue to fill in some hidden fields that are off screen.

i would have thought that most browser autofill extensions would be designed to only fill in details once, but who knows

[troyvit]

It seems like it would help if a password manager gave a warning before/instead of filling out multiple logins on one page. I log into a fair number of different sites in none of those do I want fill out multiple fields on the same page.

[chill1]

> If a site is vulnerable to XSS it's basically game over security-wise.

Another reply seems to have focused on having XSS causing an attacker to gain access to session cookies. But no one has mentioned using Content-Security-Policy [0] - which if set properly can make it nearly impossible to exploit an XSS vulnerability in the first place.

[0] https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

[eganist]

csp is basically only useful when eng teams don't rely on unsafe-inline and unsafe-eval as a crutch.

which far, far too many apps do.

[hklutryhgg]

> If some site has an XSS vulnerability, then they've already got access to my session cookies

Not true if the website uses HttpOnly session cookies as they should.

[tmsbrg]

They don't need your session cookie either. An attacker can just use XmlHttpRequest to perform any actions as you on the website, and read the web page results. E.g. go to your profile and steal all your personal data.

They can also set up a keylogger or fake login screen and wait for you to type or paste in your password yourself.

I've always thought HttpOnly cookie flag is overrated. Stealing the session cookie may be the easiest attack but it's hardly the only.

[hklutryhgg]

I'm pretty sure you can defend against this with javascript script hashes and restrictive CSR's, but yeah, they are quite involved to setup.