Matthew N. [:MattN] Reporter
	Description • 9 years ago

<input type=password autocomplete=new-password> can be used to indicate that a password field is for the user to create a new password and therefore we shouldn't autofill/autocomplete a saved password in it.

Example use case: Prevent autofilling the administrator's password into the password field of a user edit page when changing some other detail about the user's account.

A risk is that it will be used to prevent autofill on login forms i.e. a new way to do @autocomplete=off that goes against the user's control

The above example could instead be addressed by having the username in a field with the autocomplete field name of "username" on the user edit page as we shouldn't be auto-filling the administrator's password when the username doesn't match.

	Dan
	Comment 1 • 9 years ago

While I welcome a way to prevent autofill for admin forms (see comments on bug https://bugzilla.mozilla.org/show_bug.cgi?id=917325), this bug seems very misguided.  First of all, the whole point of bug https://bugzilla.mozilla.org/show_bug.cgi?id=956906 was to prevent the site from disallowing autofill.  This would give that functionality back (as noted in the first post).

I think a better option would be to save the form "action" attribute along with the saved password, and ask the user if they want to autofill forms with different "action" attributes.  Or, alternately, you could autofill the form, having a notification that the form was "autofilled" and allow the user to say "undo and don't fill this form in the future" (and then blacklist the form by "action" value).

As password managers become more important, it would be a pity if web admins could prevent saved or autofilled passwords.  The user should be able to decide, on a form by form basis, if the autofill and/or saving of passwords will be allowed.

Vinnyjames in the other thread had a suggestion that somewhat mirrors my own thoughts.  The browser user should be in control.  He suggested notifying the user that the website does not want them to save their password, but allowing them to override that policy.  This lets the user know it is the website's fault, and not Fx's.  While this is a good idea, it does not solve the problem of admin forms being autofilled. I would take it one step further and notify (perhaps with "new-password") that "the website indicates this is a 'password reset' form and should not be autofilled with your current password--would you like to prevent this form from being automatically filled in?"  Perhaps a little too verbose for the average user...

Unfortunately we cannot rely on web designers to correctly use options that prevent saving of passwords.  Therefore, we cannot give them the options without allowing user override.  If we allow user override, we must provide an interface to deal with that.  Simply requiring a different attribute value for the same behavior doesn't solve the problem.

	Matthew N. [:MattN] Reporter
	Comment 2 • 9 years ago

I think if we implement password generation UI (bug 376674) on fields with @autocomplete="new-password" as soon as we start supporting that value then it will discourage sites from abusing it since it will lead to confusing UX for their users.

	Dan
	Comment 3 • 9 years ago

Hmm, that is a good point.  That's kind of a funny way of encouraging sites not to abuse it, but if that's the default behavior, it could actually work.

	florian.thoni
	Comment 4 • 8 years ago

Indeed, here we have a big issue with that behavior.
Let say we have an application (ttrss), that allow to subscribe to rss feeds, potentially private ones.
It has an option to add authentication on it. Those fields must remain empty if no authentication.

However, with this behavior they are automatically filled in with the user and password of the application itself that will be surely different of the target feed user/password and will send by curl this to an external site.

What do you recommend in such a case, if the team decide to continue to ignore that "new-password" directive ?

Thank you

	greg
	Comment 6 • 8 years ago

We use password fields to let users enter private info (potentially passwords) when running Jobs in Rundeck (http://rundeck.org).  Using 'new-password' allows us to prevent autocomplete.  This does not work in Firefox.  (see https://github.com/rundeck/rundeck/issues/2015 and https://github.com/rundeck/rundeck/issues/1966 )

There are many use cases where preventing the user's login password from autocompleting in a password field in a web application is desirable.

I think Firefox should behave the way Safari and Chrome do, and honor "new-password", to at least allow compatible behavior.

Safari pops up a small drop-down menu when you start typing in a username field, and lets you select whether or not to fill in the password, this is a smart compromise between doing it all the time and letting the user choose.

Ideally, I think password autocomplete should allow the user to select when and if to fill in the password.  For example: "Automatically fill my password on this site: [ ] always [ ] only this page [ ] never" or something similar.

	Steve C.
	Comment 7 • 8 years ago

(In reply to Dan from comment #1)
> First of all, the whole point of bug
> https://bugzilla.mozilla.org/show_bug.cgi?id=956906 was to prevent the site
> from disallowing autofill.  This would give that functionality back (as
> noted in the first post).

I'd like to add a point of clarification. After reading the entire thread for bug 956906, I think it's safe to say that this isn't quite accurate. Manish G. partially summarized the change this way:
> This change makes it so that `autocomplete=off` does not stop the Password Manager from working.
> Normal form autofill can be disabled as usual.

Before him, Dave G. put it like this:
> For the eleventy billionth time, this change was only to allow the password manager to
> remember passwords at the request of the user.
> The autocomplete="off" flag is still intended to work for forms in general as it always has.
> The password manager and the form autocomplete systems are separate,
> and this bug was never about the later.

I think it's important to make the distinction clear here because I've been running into autofill issues with FireFox and, in most of the reading I've done to try and solve them, I've noticed people conflating the password manager with autofill and autofill with autocomplete.

I'm developing a B2B web app that gives admin from a particular business the capacity to associate their company's ConnectWise Manage credentials with all users from their business so that those users can import data about their clients and projects from ConnectWise. 

In order to capture those credentials, I've made a form that is similar to a user update form, but that instead updates data for all users associated with a particular business. This page has five input elements, each on its own row: Host, Company ID, Public Key, Private Key, and Your Password. The first three are type="text", but Private Key and Your Password both have type="password".

The problem I'm having is that the user login credentials saved in the password manager get loaded onto the page, despite whatever values I've set autocomplete to. Specifically, the username gets loaded into Public Key and the password gets loaded into Private Key.

I have no problem with users saving passwords for the app; I find it fairly convenient, myself. The issue here is that this isn't a login form; It's effectively a user update form, but one in which the first password field would almost never be any password that one would expect to be saved into the password manager, as it's not a password for the user's account, but the business's.

I recognize that maybe I'm not technically using the password field correctly in the sense that the private key isn't exactly an account password, but changing it to a standard text field just migrates the problem so that Private Key is treated as a username field and Your Password is treated (correctly, I suppose) as the password.

For me, setting Private Key to autocomplete="new-password" would seem to be an acceptable solution, provided browsers actually honored the setting.

	rugk
	Comment 8 • 7 years ago

Supporting autocomplete="new-password" would be really nice and has many legitimate uses, e.g. when a password input field does not belong to a login/register form.
Real-world examples would be a custom decryption password (https://github.com/PrivateBin/PrivateBin/issues/118) or a password used for HTTP Authentication in the backend (https://github.com/nextcloud/news/issues/122), where having a wrong (login) password filled in, could even accidentally expose the password to third-party sites or other parties depending on what is done with the password.
Also, this feature is implemented in all other mayor browser, so supporting it in Firefox would be a good idea.

	cby016
	Comment 9 • 7 years ago

Please add support for autocomplete="new-password". Other major browsers already support this and for compliance reasons we can't allow users to save passwords on our site. If this does not get fixed on firefox we will have to force our users to use Chrome, Safari or IE.

	rugk
	Comment 10 • 7 years ago

Actually your comment shows the big reason behind not adding this field. When you cannot do this "for compliance reasons" your compliance is broken and Firefox is doing exactly the correct thing: Not to allow this.
You *must not* disallow users to save passwords when they are real, good passwords. Saving passwords is a security feature. Password managers are a security feature. Feature, not bug! If you don't get this, you're doing something very wrong.
And you can't prevent users from doing t6his anyway BTW. They could always use a third-party password manager and/or just copy & paste the password or e.g. modify the HTML code with the browser's development tools.

And have a good attempt forcing your users to use other browsers. Haha…

So, @cby016, the fix you need is easy: Remove autocomplete="new-password". It makes no sense in your case.

	cby016
	Comment 11 • 7 years ago

If it were up to me I would allow users to save their password. Maybe you can tell the government that their "policy is broken" and they will change it. However until then we will have to direct our users to other browsers that do support this feature. That actually shouldn't be a problem since only about 5% of our users are using Firefox.

From what I understand, autocomplete="new-password" is part of the standard, and all major browsers support it except Firefox. I thought Firefox was a standards compliant browser.

Also @rugk, 2 months ago you posted in favor of implementing this feature. I'm not sure why you posted such a condescending response to my post that is asking for the same thing.

	rugk
	Comment 12 • 7 years ago

LOL, only 5% of your users are Firefox users. In this case you don't need to worry…
Because I was asking for a legitimate use case. To clarify:

Legitimate:
* as the name implies: for setting a new password
* passwords, which actually are not login passwords and make no sense to be stored.

Not legitimate:
* Forcing users to nopt store passwords.

	lastresort
	Comment 13 • 7 years ago

This feature should be implemented.

Our software allows the admin to create new users. If you store the password you'll always get yours filled into the fields for the new name and password. Also there's a configuration site where you're able to configure smtp data. You always get the password field and another field which isn't even a username field filled by fault because of autocomplete. If you don't notice that before you save the config it leads to a wrong configuration which affects our software.

I guess there are many other cases in which ignoring this flag ends up in very bad user experience.

Sure, it also can be used for "not legitimate" cases, but if the user notices such a case he could simply don't use the site anymore.

In total I'd say you do more harm than good to the user by ignoring this flag.

	gulty
	Comment 14 • 7 years ago

Not allowing new-password is doing more harm than good. There are so many usecases where you can login as an admin and manage other users. If passwords are prefilled you can (if you do not pay attention to the autofill) change a users password when saving by mistake. If you want to activate a feature in a users account for instance. Or adjust anything else in the user profile.

Overall it's not a good idea to assume that the login credentials are valid/wanted for all types of password fields on a site. This is simply a wrong behaviour. For most sites it might be a good thing but for CMS or other business sites you cannot assume that this is the default behaviour.

You need to implement a way for the developers to avoid the autofill for places where it's not supposed to take effect and for places where it's simply wrong and would make the user experience worse!


+1 for adding "new-password" according to the standards. Firefox doesn't have to be the only exception where this is not working.

	Kacper
	Comment 15 • 7 years ago

I can't believe this is not yet implemented. I am having HUGE issues with a CRM system where admins have power to reset users' passwords by typing them manually into a password-type field.

Unfortunately, the password reset field is not normally visible (it is hidden from view by JS). Because of lack of support for autocomplete="new-password", whenever an admin edits a user's record, that record's password gets updated to admin's own password. This is a HUGE isssue that has now forced manual processing of hundreds of records on us. As a result, we are now having to ban Firefox from being used with the CRM.

To stress once again: a "password"-type field serves also other uses than for the current user's account password. In real life, it is used to store hashes, keys, ids, and so on. Autofilling it with a user's password is a bug.

	roelharbers
	Comment 16 • 7 years ago

According to https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion#The_autocomplete_attribute_and_login_fields :

"If an author would like to prevent the autofilling of password fields in user management pages where a user can specify a new password for someone other than themself, autocomplete="new-password" should be specified, though support for this has not been implemented in all browsers yet."

Guess which browser hasn't implemented it yet...

Currently, I'm having issues with a page where the user can set his own password (using a password reset link): because there's no username field (which wouldn't make sense, because a guid in the link determines the username), the password manager just puts the username into the nearest input before the password field, which happens to be an otp field in my case.

How do I tell Firefox that this is, indeed, NOT a login screen?

	roelharbers
	Comment 17 • 7 years ago

To add: This is basically my password reset page:

https://jsfiddle.net/2eazsvqt/4/

the password manager seems to assume the otp field is the username because reasons. Reloading then fills the otp field with that stored "username"

My solution is to add a hidden input just before the password field, which tricks firefox into filling that field with the "username" instead of the otp field:

https://jsfiddle.net/2eazsvqt/6/

Surely this cat-and-mouse stuff shouldn't be the way forward here.

	John Hascall
	Comment 18 • 6 years ago

It seems to me that there are two separate issues.
(1) Saving an entered password, and
(2) Filling in a saved password.

I have recently been working on our (self-service) username registration page.
(1) I would be thrilled if people are using a password manager to save the password they enter, but
(2) I *really* don't want the password they are using somewhere else to be filled in (perhaps the only password they ever use, ugh)!

So my suggestion would be that autocomplete="new-password" can (ask to) save the password (1), but will not autofill into that field (2).   If there is still worry that web designers will "abuse" this feature, I suppose you could remember the exact url and the id of the field and only autofill on an exact match.

	Keith Maika
	Comment 21 • 6 years ago

Running into this issue currently while implementing a user add/edit page which includes the ability to change the user's login information.

I think a good solution here would be to make a field with autocomplete="new-password" act the same way as a password field does when there are multiple logins saved for the same site.  In this situation, when the field is focused a small popup appears displaying each saved username and when selected the field is populated with that username's login.

This approach means that the field is not pre-filled so accidental submissions are avoided, but still allows a user to easily auto-fill the form limiting the potential for sites to abused it as a means of preventing password manager user.

	RedScourge
	Comment 22 • 6 years ago

A good solution would be anything which somehow requires the user to actively do a non-default thing, rather than making the browser callously override the almost certainly deliberate intentions of the web developer by default. Preferably, in a way where it isn't anything resembling a default option, as there are countless millions of users who seem to just assume that they have to click whatever "Ok" option gets in their way without reading it, in order to get where they want to go. 

That way, everyone gets what they want; the developers get some semblance of expectation that their code will do what it is supposed to do unless the user goes out of their way to override it, users who know what they're doing get to override it in the unlikely event they want to, and everyone else who doesn't much care to do so gets the developer's intended user experience.

	jonlennryd
	Comment 24 • 6 years ago

Hi, I work with a web-based-system used in schools where the computers are shared. It means the same student does not have their own computer but instead are given a computer or sometimes an iPad at the beginning of the class.

The problem of auto-completion becomes quite obvious in this scenario! The login page should not have autocomplete, neither the edit user account form. The teachers are not always aware of the security issues and do not disable any password-storing functionality in the browsers. On top of this students, on the other hand, are very aware of how to 'hack around', and can easily change settings in a browser, which might remain until next class. 

I would like to be able to completely disable auto-completion on both passwords, and username-fields. We have already misused Chromes autocomplete="new-password" to at least disable the possibility for another student to change other students passwords during class! ;)

	Laurențiu Nicola
	Comment 25 • 6 years ago

@jonlennryd You can use different OS accounts, or at least the policy support (about:policies#documentation and Google) to disable the password manager.

	gulty
	Comment 26 • 6 years ago

@jonlennryd: for your purpose IMO you are wrong here. You should be disabling autofill in the browser settings and restrict the access to them. Or let everyone create an own user account.

	RedScourge
	Comment 27 • 6 years ago

(In reply to Laurentiu Nicola from comment #25)
> @jonlennryd You can use different OS accounts, or at least the policy
> support (about:policies#documentation and Google) to disable the password
> manager.

Do you mean going to about:config and changing values? because "about:policies#documentation" doesn't work in the latest version of Firefox. 

I would assume that perhaps one could set defaults to false to disable autofill, correct? Is there a way to do this via AD Group Policy in Windows though, so that a sysadmin doesn't have to log on to every computer in their organization as every user and change this option manually in order to ensure this functionality is disabled? Because if not, this is pretty much an insufficient solution for corporate environments, which one would assume is probably the main sort of environment where it may be useful to disable this functionality.

	Laurențiu Nicola
	Comment 28 • 6 years ago

(In reply to RedScourge from comment #27)
> Do you mean going to about:config and changing values? because
> "about:policies#documentation" doesn't work in the latest version of
> Firefox.

It should work AFAIK (I'm on Nightly). Try about:policies instead.

> I would assume that perhaps one could set defaults to false to disable
> autofill, correct? Is there a way to do this via AD Group Policy in Windows
> though, so that a sysadmin doesn't have to log on to every computer in their
> organization as every user and change this option manually in order to
> ensure this functionality is disabled? Because if not, this is pretty much
> an insufficient solution for corporate environments, which one would assume
> is probably the main sort of environment where it may be useful to disable
> this functionality.

https://support.mozilla.org/en-US/products/firefox-enterprise
https://support.mozilla.org/en-US/products/firefox-enterprise/policies-enterprise
https://support.mozilla.org/en-US/kb/customizing-firefox-using-autoconfig

They do have a set of ADMX templates, which should be enough. You can also deploy a policies.json file, or even override about:config preferences.

---

Also, if you care about security, don't share accounts between professors and students. You're just one keylogger away from compromising everyone's credentials.

---

Since this was kinda off-topic, here are some thoughts about the requested feature. If it's implemented, it *will* be abused by special snowflake websites like seen in comment 10. If you want security for your users, implement a form of two-factor authentication like TOTP, don't trick the browser to disable its password manager. I'd rather user per-site randomly generated passwords than a single password everywhere, because I don't trust some of these snowflakes to care about KDFs and password salting. And it's *my* browser, so keep your hands off it.

As for the "legitimate" use case, is having to delete or replace an auto-filled password such a hassle? I'm sure there might be users who have trouble with that, but that's something inescapable. You probably have other features these users are having trouble with, so you still need a way of supporting them.

	jonlennryd
	Comment 29 • 6 years ago

Thanks for all the links and info! 

Reality sucks though, as many schools do not have any security personnel worth its name. Also, a school is a bit different world than the normal internet world, since the one sitting next to you can snatch your iPad for a moment and make a mess, just for the fun of it. That's the "use case" we are thinking about in general, because it happens from time to time. With the password autocomplete turned off, a typical change-password-page would not allow a stranger to change your password. (as it requires you to enter your old password, which in this case are auto-completed by the browser)

I agree it is a pretty specific problem, and it can be fixed simply by turning off the password vault in the browser. On the other hand, it surprises me there is no way for a webpage-maker to simply opt out of password auto-completion. I understand the discussions, for example, https://bugzilla.mozilla.org/show_bug.cgi?id=956906 makes sense. It is just that all these discussions assume each person have their own computer/pad which they have full control over.

	RedScourge
	Comment 30 • 6 years ago

Really what would be an optimal solution would be if a new type=obscuredtext option and a new type=username option were added to the HTML standard, and thereafter type=username and type=password would become the standard field types for web developers to use for login form username and password values, and the standard field types to trigger browser password managers. This would free up everyone from the confusion of knowing whether a given type=text field is supposed to be a login form username, 
and whether a given type=password field is supposed to be for a login form password or if the web developer had some other intended purpose to obscure a field.

This solution would allow there to never be any doubt in the minds either of web developers or browser developers what the intention of these form field are, and which form fields the password manager may/should attempt to use and which it should not. While having the added bonus of making HTML more semantically intuitive, and the added bonus of eventually allowing browser developers to remove the code which tries to figure out which text field to treat as a username whenever a password field is present in a given form, most importantly it would completely prevent a potential arms race between web developers who may want a particular obscured text field to not trigger the browser's password manager for some reason, and browser developers wanting to trigger the password manager on every form containing a type=password field in case a user might want it to, regardless of any problems caused in certain applications.

It would however be difficult and time consuming to get everyone else on board with altering the HTML standard accordingly, so a good compromise would probably be to implement the already existing and increasingly supported autocomplete=new-password functionality instead.

	goodoldgrim
	Comment 31 • 6 years ago

This is such a misguided arms race. I will create the password field at runtime with a random id and obscure the input with JS that hides characters as they are typed and stores them in memory, if necessary, but if I decide a field is not getting autofilled, it's not getting autofilled.

Same as others, I have nothing against password managers - my use case is an admin form.

The only sane solution is a notification that the web page is blocking autocomplete of that field and an option for the user to override it. Then the control is still with the user and programmers who just want an obscured field not to get autocompleted can go about their day without this inane hassle.

Those who want to disable password managers will find a way. The arms race is a waste of everyone's effort. It should be focused on educating people about benefits of password managers instead.

	Pulsebot
	Comment 38 • 5 years ago

Pushed by sfoster@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/32c7dc092efd
Don't autofill password fields with autocomplete=new-password. r=MattN

	Pulsebot
	Comment 42 • 5 years ago

Pushed by sfoster@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/0cb8b8db9618
Don't autofill password fields with autocomplete=new-password. r=MattN