When passwords are autofilled by the Password Manager, javascript on the page can read the filled in passwords even when the user has no intent to login to the page. Hence, pages that are vulnerable to javascript injection (via XSS or MITM) are also subject to password exfiltration attacks[1] (in some cases without any indication to the user that such an attack has taken place). To protect against this, we should not autofill passwords without user interaction / user intent to login. This protects users from a number of the drive by attacks and protects users who never planned to login. From a usability perspective, it is debatable whether or not autofill is a good user experience. It allows for an easy and frictionless login, but can also cause confusion (how did my password get filled in?). Discussion about a more active login experience (rather than a passive one) are underway with UX. If we do decide that we need to continue with an autofill experience, then there are cases where we definitely should not autofill. (Note that this will make a less consistent experience for users and won't protect us on a page with an XSS vulnerability.) In the below cases, we MUST not autofill: * For http sites (IE 11 has this security feature) * https sites that have mixed active content * https sites that require a cert override (chrome does this) * in iframed sites (safari does this for non-same origin, chrome does this for all frames). * Invisible form fields (visibility and opacity, although this isn't going to prevent clickjacking attacks to autofill the passwords) Previous bugs have been filed to address subsets of this problem. I've added them to the dependent list. [1] https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/silver

I don't think we're going to get rid of auto-filling entirely. Restricting it in certain cases is reasonable. I think if we want to tackle the XSS vector we should do so with an approach like bug 653132 (which will be difficult to get right).

> I don't think we're going to get rid of auto-filling entirely. The current experience is that sometimes the creds are autofilled and sometimes they aren't (due to autocomplete=off logic, I believe). The result is an inconsistent, confusing user experience where it's unclear who is doing the filling. Is it the site, is it the browser? As a user, what do I do to fix it when it's not autofilled? I think we should experiment with different options that address both the security concerns and the UX inconsistency. One clear, consistent option is to always require user action to fill. It remains to be seen whether it's ultimately acceptable, but we shouldn't be afraid to experiment with it.

> I don't think we're going to get rid of auto-filling entirely. Something that may be viable is a variant of bug 653132 which makes non-autofillable forms *appear* to be autofilled until the user interacts with it. I don't agree with the exact rules suggested in bug 653132 for when to provide the real values to the page, but this idea may have some legs to support the "always autofill" option.

What is the point of saving passwords via Password Manager if they are not to be autofilled?

> What is the point of saving passwords via Password Manager if they are not to be autofilled? The point of saving passwords for users is to make it easier for them to log in to that site in the future. Autofilling the login form on page load is one approach, but there are others.

In reply to David E. Ross from comment #4) > What is the point of saving passwords via Password Manager if they are not > to be autofilled? Obviously we want the password manager to fill in the password field at the right time, that's not what Tanvi means in this bug. What we're getting at is hard to fit in a bug summary: Don't magically fill the fields on page load without some indication the user wants to interact with the field. Figuring out what action triggers autofill might be hard, but it's probably better to user-test a bunch of things rather than to try to do it as a purely mental exercise. * fill on user (non-synthetic) click in the form? * put a widget/button in the password field? - if only one saved for site fill user/pass - if multiple open a context menu for picking * something else? bug 653132 is an alternate approach to the same risk we're worried about with the solution in this bug. (In reply to Chris Karlof [:ckarlof] from comment #2) > The current experience is that sometimes the creds are autofilled and > sometimes they aren't (due to autocomplete=off logic, I believe). The result > is an inconsistent, confusing user experience Autocomplete=off prevents us from /saving/ passwords, doesn't seem to prevent us filling in passwords we know. These days it might change the way we autofill by switching to the multi-value UI, but since I get that UI all the time (signon.autofillForms set false) I wouldn't notice. There are many other ways sites actively subvert our heuristics to capture passwords, and if they're not captured they can't be replayed. Sometimes sites subvert our ability to replay into fields (I'm looking at you, mozilla.okta.com) even if we did capture the password. We also store login form metadata such as the form submit hostname and we won't replay if that changes (might be an exfiltration attempt by an injected form, if we assume script-injection was prevented). We also store the username and login field names. If we're using them to replay that could certainly be a source of fragility. I don't know if we actually use those, but if we put replay widgets into the forms themselves we wouldn't need to because the user's click action would tell us exactly what form they intended to fill. Of course a replay widget in page a hijacked page is susceptible to clickjacking, but if a page the user really wants to interact with is hijacked they're going to lose. What we want to prevent is mass password harvesting if no user interaction is required.

FWIW, here’s my current thinking about this: 1) Autofill with the last used username/password on sites where it’s “safe” to do so. What's "safe" and "not safe" is TBD, but the list in this bug description is a good starting place. 2) Make it “appear” (to the user) that the credentials have been autofilled on sites where it’s “not safe” to do so (e.g., non-HTTPS sites). When the user signals in some way she wants to log in on that page (specifics TBD, but e.g., focusing one of the fields, submitting the form, clicking a “login” button), we autofill for realz. We need to do this early before the page has had a chance to react to any user input. 3) If the technique in 2) works well, we could make that default approach for all pages. I'm hopeful this approach will give us a nice balance of security and UX consistency.

(In reply to Chris Karlof [:ckarlof] from comment #7) > 3) If the technique in 2) works well, we could make that default approach > for all pages. > Why not start off with all pages? That way, an XSS on an fully HTTPS page won't affect a user who never intends to login to the website.

> Why not start off with all pages? That way, an XSS on an fully HTTPS page won't affect a user who never intends to login to the website. Because it's unproven and currently unclear (at least to me) how we would implement it. We need to know it works well before it becomes the default experience. FWIW, using it only on "unsafe" is not only way of gaining experience with it, though.

(In reply to Chris Karlof [:ckarlof] from comment #7) > 1) Autofill with the last used username/password on sites where it’s “safe” > to do so. What's "safe" and "not safe" is TBD, but the list in this bug > description is a good starting place. Nitpick: "last used" sounds like it makes it harder to discover the fact that multiple logins might be saved and to select a not-last-used one (right now we do not auto-fill and a double-click on the user name field reveals all saved ones, clicking one from the list auto-fills - that's not very discoverable but still somewhat easy to fill in any of them when you know who to get the list).

(In reply to Chris Karlof [:ckarlof] from comment #7) > FWIW, here’s my current thinking about this: > > 1) Autofill with the last used username/password on sites where it’s “safe” > to do so. What's "safe" and "not safe" is TBD, but the list in this bug > description is a good starting place. The devil's in the TBD. My concern here is that the "not safe" conditions are not going to be understandable by users, which results in a UX where sometimes autofill works, and sometimes it doesn't. My current understanding of the TBD details is that this would common enough to be a problem, but if we're able to narrow that down to more exceptional/understandable situations, that makes this feasible. I'm sorta leaning towards ensuring consistent UX by never autofilling, and having good and obvious UI so that the manually-triggered fill is a single click/keypress. > 2) Make it “appear” (to the user) that the credentials have been autofilled > on sites where it’s “not safe” to do so (e.g., non-HTTPS sites). When the > user signals in some way she wants to log in on that page (specifics TBD, > but e.g., focusing one of the fields, submitting the form, clicking a > “login” button), we autofill for realz. We need to do this early before the > page has had a chance to react to any user input. I'm particularly wary of the details here. Might be doable, but the details seem like a mess. We'd at least need widget support to make the fields work that way, need to figure out interaction with HTML5 form validation, deal with sites that do their own input checking, and somehow make this work on sites that perform the login action with XHR.

I'm doing some "wave a magic wand" thinking here, and I recognize it may not feasible. I'd like for us to scratch our heads a bit more, though.

This is a product decision on how we approach this: NI to Bill

The use of Password Manager can actually provide better security than manually filling passwords. Manually filling passwords often leads to very simplistic, easily-remembered passwords; passwords on PostIt notes stuck to monitors; and keeping passwords in unencrypted text files. What is needed is Password Manager to have enhanced encryption of its database and (as suggested in comment #6) to have some form of confirmation that the user does indeed want the password filled-in.

(In reply to David E. Ross from comment #14) > What is needed is Password Manager to have enhanced encryption of its > database and (as suggested in comment #6) to have some form of confirmation > that the user does indeed want the password filled-in. This bug is about the second half of what you propose (bug 1118549 is the first part): We should not fill in the password automatically but instead have the user confirm in some form that it's being filled in. It's not clear yet what kind of UI we should have for the user triggering passwords to be filled in, AFAIK.

No magic wand here. To summarize: There's a realization that we should try to either autofill all the time, or none of the time, but not part of the time, and that the security concerns are real. So if we can figure out a way to provide users with a clear and easy way to trigger autofill, we would protect them more and confuse them not too much. As people have pointed out, this imagined experience will be probably always be far from perfect, because of the heterogeneity of pages and the fact that sites in many cases don't share our goal of helping users log in faster. 2. We need user testing to see which works best. I am gong to work with UR and Ux to get it done this quarter, probably in the form of a limited study. We can test the following: 1. Triggering fill on user interaction (click, focus, etc). 2. Putting something in the password field for user interaction (this will be hard) 3. Use of other mechanisms (I have a wand on order) 4. The multi-login experience can also be covered, but won't work for the majority of logins which are single user. I do think if we decide to do this for the good reasons discussed here, Firefox will be potentially doing the right thing for the user, but it the experience will be different (and likely slower) than Chrome and also Edge, which appear to autofill as much as possible.

I won't be working on this bug. But we do need to stop autofilling, at least on HTTP pages.

(In reply to Tanvi Vyas - out on leave [:tanvi] from comment #17) > But we do need to stop autofilling, at least on HTTP pages. This was implemented for HTTP pages so lowering the priority. We could support signon.autofillForms in preferences…