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.
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.
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.
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.
i would have thought that most browser autofill extensions would be designed to only fill in details once, but who knows
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.
which far, far too many apps do.
Not true if the website uses HttpOnly session cookies as they should.
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.
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.)