Password manager fills logins into wrong / undesired fields

RESOLVED WONTFIX

Status

()

Toolkit
Password Manager
RESOLVED WONTFIX
8 years ago
10 months ago

People

(Reporter: Dolske, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

8 years ago
[Filing this as a new bug, as a well-defined bug to dupe existing/future bugs to.]

The new password manager, introduced early in Firefox 3 (bug 374723), changed the usage of form input names when filling in a form.

Previously, a login would only be filled into a form when the saved field names exactly matched the input names on the form. This resulted in a few problems. Sites might change field names when rolling out a new version of the site, or were using different field names on different parts of the site. [EG, the main login page might have <input name="passwd">, a subpage might have <input name="password>, and and account management page might have <input name="old_password">].

This resulted in the password manager not working very well, because it wouldn't fill in these other forms on the site. From the user's point of view, this seems broken. The user would have to enter their login on each slightly-different form, and the password manager would offer to save each of these variations separately. This also led to confusion when changing a password, because only 1 of these logins would get changed and so logging in from a different page would fail until corrected.

Part of the problem here is that there's no specification for how login forms should be organized, or requirements for (re)using field names. Password managers basically have to guess as to what should be remembered/filled on a form.

The new password manager no longer uses the field names. Instead, it takes the heuristics it uses during form submission (for finding a login to remember), and reuses that same logic for filling in a form when a page loads. This allows it to make use of a login even when the field names are different, and helps ensure that if it knows how to save a login then it can fill it back in, and avoids needlessly saving multiple logins.

The unfortunate side effect of this is that sometimes the login manager can fill a login into a form where it's not wanted. From the password manager's point of view it *looks* just like a login form, but it doesn't know the actual context of the form. [Note that this isn't a security issue, it still restricts logins to matching scheme+host+port and form submit URL. Form field names are not a security mechanism.]

Due to the inherent ambiguities in form-based logins, there's an unavoidable tradeoff here between making the password manager work on lots of sites, and having it match the behavior of the old FF2 password manager (which checked field names). We've chosen to go with better functionality in the new password manager.

There are a few workarounds that sites can use when encountering this issue:

1) Set the |autocomplete="off"| attribute on the inputs or form in question. This will stop the password manager from filling in those fields, and will also stop it from remembering values entered into those fields. Often bugs are filed saying we shouldn't fill these fields in, but the site really wants to also suppress saving these logins, so this is a good solution to fix both issues.

2) Adjust the order of the form. When saving a login is desirable (eg, in a account creation page, or change-password page), ensure that the first password field is preceded by a text field for the username (and not some other field, like a email address or telephone number). If needed, the field can be hidden with style="display:none".

3) Prefill the field with a value. The password manager will not fill in (overwrite) a form field's value unless it matches the username/password of the login it wants to fill in.

4) Make the field initially disabled, read-only, or maxlength=0.
(Reporter)

Updated

8 years ago
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX
(Reporter)

Updated

8 years ago
Duplicate of this bug: 463388
(Reporter)

Updated

8 years ago
Duplicate of this bug: 478678
(Reporter)

Updated

8 years ago
Duplicate of this bug: 488819
(Reporter)

Updated

8 years ago
Duplicate of this bug: 491157
(Reporter)

Updated

8 years ago
Duplicate of this bug: 496838

Comment 6

8 years ago
This is not "better" functionality.  It's far less secure functionality that forces web developers to cater to FF3 quirks if they want to use additional "password" type input fields within their websites for other than authentication.  I would much rather have to choose from a list of usernames and passwords stored for a particular domain when field attributes change than have Firefox auto (and silently) fill in my username and password whenever it encounters input "text" followed by input "password".  The "heuristics" that Firefox 3 is using for this is laughable.

Is the reason FF no longer uses field names because you guys are worried that site developers will change their form field names daily or hourly or what?  Is there a reason the Firefox doesn't notify when it's using a stored username and password?

Not all "password" type fields are used for Username and Password.  In our instance we had an account management page that had an account number field.  This field uses the "password" type to obfuscate from prying eyes and has a description field before it.  The form itself is on a tab in a form that is now shown unless needed and is not required.  Our Firefox 3 users have been inadvertently entering their Username and Password information into those fields causing compromise of their personal credentials in at least 3 cases.

My only point is that the way FF3 is testing for what is username and password fields is just far too broad and apt to make a mistake.
(Reporter)

Updated

8 years ago
Duplicate of this bug: 500505

Updated

8 years ago
Duplicate of this bug: 506046
(Reporter)

Updated

8 years ago
Duplicate of this bug: 514889

Updated

8 years ago
Duplicate of this bug: 536351

Updated

8 years ago
Duplicate of this bug: 454274

Comment 12

7 years ago
Is this a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=655669 ?

Updated

5 years ago
Duplicate of this bug: 818064
Duplicate of this bug: 823876

Comment 15

4 years ago
No, the other one is a duplicate of this here.
However, this bug should be reopened resp. should have never been closed as WONTFIX. Looks like that's been unintended anyway.
Flags: needinfo?(dolske)

Updated

4 years ago
Duplicate of this bug: 655669
(Reporter)

Comment 17

4 years ago
I have no idea what you're asking. But this bug is 5 years old, so isn't the right place to be asking.
Flags: needinfo?(dolske)

Comment 18

2 years ago
As autocomplete="off" is now ignored by password autofill (Cf. https://support.mozilla.org/en-US/questions/1064817), this bug should be reopened.

Password autofill occurs on any form containing an empty text field and a password field, causing fields to be incorrectly filled on some forms – like user settings where a user can fill in their details, as well as changing their password:

<html>
  <body>
    <form>
      <label>Name:</label><input type="text" name="name" value="John Doe"><br>
      <label>Biography:</label><input type="text" name="biography"><br>
      <label>Password:</label><input type="password" name="password">
      <input type="submit" name="save" value="Save">
    </form>
  </body>
</html>

Comment 19

2 years ago
(In reply to slc_ie from comment #18)
> As autocomplete="off" is now ignored by password autofill (Cf.
> https://support.mozilla.org/en-US/questions/1064817), this bug should be
> reopened.
I think so as well. This has become quite problematic in "edit profile/user" contexts where passwords can be set/changed.

Comment 20

10 months ago
We are experiencing similar problems, but with filling in not passwords, but login name into wrong field on wrong page...
You need to log in before you can comment on or make changes to this bug.