107

Currently, there is an HTML form/input attribute called autocomplete, which, when set to off, disables autocomplete/autofill for that form or element.

Some banks seem to use this to prevent password managers from working. These days sites like Yahoo Mail seem to do it as well because they feel that password managers are unsafe.

A few weeks ago I implemented a feature in Firefox that gives the user an option to override this for username/password fields only (i.e. to disable the password manager). There now is a request that is asking for it to override autocomplete=off by default. Quoting the issue:

This behavior is a concession to sites that think password managers are harmful and thus want to prevent them from being effective. In aggregate, I think those sites are generally wrong, and shouldn't have that much control over our behavior.

This makes sense to me, for similar reasons as the ones in this comment by BenB.

autocomplete=off has been abused a lot recently. Yahoo started using it for their login (including webmail and my.yahoo.com), which is why I stopped using Yahoo. Webmail apps - even some bigger providers - now use it, which was decidedly not the purpose. The admins are very self-righteous, and insist that the keep this "for security" because password saving "is unsafe".

They are misguided, because

  • keyboard loggers exist and are widespread, probably more widespread than malware that can read Firefox password store.
  • even simple attacks by the little nephew exist: Just look over the shoulder
  • possibly most importantly, forcing users to re-enter their password every time practically forces them to use a simple password - easy to remember, easy to type, probably even used on multiple websites. This obviously lowers overall security dramatically and thus poses a danger to security.

So, autocomplete=off is actively harmful for security.

And a massive pain for end users, without a recurse for them apart from severing entire customer relationships.

There have been many workarounds (usually bookmarklet-based) that have been posted on the Internet. IE11 has already removed support for autocomplete=off.

The question is twofold:

  • Is there any significant increase in security for a website when it uses autocomplete=off on password fields? Or is it actually harmful to security as per BenB's comment?
  • Should browsers allow this attribute by default and give this much control to the website? (This bit is subjective, feel free to not answer)

While my situation is specific to autocomplete=off for username/password fields (the code only affects the password manager), I do welcome input on the broader aspect of disabling autocomplete=off

Improve this question
11
  • 9
    What a terrible, terrible option. BenB is completely off-base. As Lucas mentioned, autocomplete=off has nothing to do with whether password managers are "safe" or not. One case he didn't mention is DOM injection/XSS, which can and has (MySpace is one example, IIRC) been used to take advantage of inadequate input validation to add an illicit hidden login form to arbitrary pages in an application to steal the credentials of users who use form auto-complete for credential storage.
    – Xander
    Jan 25, 2014 at 15:48
  • 4
    This question is talking about the password manager, not the form fields autocomplete (despite the wrong title of the question). The password manager only stores after user confirmation, never automatically. It also has a store separate from the form field autocomplete - in fact, it's a completely different implementation in Firefox. Thus, mentioned scenarios of unknowingly storing passwords in Internet Cafes don't exist with password fields.
    – user37982
    Jan 26, 2014 at 21:04
  • 3
    @user37982 That is not correct. There is an assumption in the question that the reason might be to prevent password managers from working, and then the question wanders in that direction, but that is a bad assumption to begin with.
    – Xander
    Jan 27, 2014 at 20:13
  • 2
    @Xander true, though note that the bugs in question are about only the password case. I'm more interested in the impact on security by disallowing it for password fields, however I don't mind comments on the other uses .
    – Manishearth
    Jan 27, 2014 at 20:17
  • 4
    Just an FYI, from my field, we are seeing that Security related questions/MFA are basically rendered useless now. When a users fills out their security questions and have to use them, the information is now saved. So all a person has to do now is check the autocomplete. I really still do not understand why Chrome and Firefox would wish to override what a website sets a field to.
    – user49427
    Jun 16, 2014 at 16:21

5 Answers 5

Reset to default
58

The problem is that this one setting simultaneously controls the behavior of two similar but sufficiently dissimilar functions in the browser such that an optimal result is difficult to achieve.

First, we have what you might call "smart" or "naïve" or "automatic" auto-complete.

This is the original auto-complete technology. As you fill in forms on various sites, the browser watches the names of the forms and the contents you fill, and silently remembers the details. Then, when visiting another site with a similar-looking form, it "helpfully" fills in fields using the values it filched from your previous behavior on other sites.

The idea here is to save you time without any configuration or decision-making on your part. Filling in your name? We'll automatically fill in the name you used last time. Filling in a credit card? We'll fill in the credit card you used elsewhere.

In its zeal to be helpful, the browser is sharing your secrets from one site with all the others, just in case it's what you wanted. From a security perspective, this is a disaster for all the obvious reasons and for several non-obvious ones as well. It has to be disabled, and probably shouldn't have ever been implemented to begin with.

Second, we have "explicit" or "secure" or "configured" auto-complete

This is the world, primarily, of saved usernames and passwords. In this incarnation, the browser saves your form data only with your explicit approval. Ideally, it stores that data in an encrypted store, and most critically, the data is firmly associated with a single site. So your Facebook password stays with Facebook, and your Amazon address stays with Amazon.

This technique is critically different in that the browser is replaying saved behavior when the matching environment is detected. By comparison, the other technique is anticipating desired behavior automatically by looking for similarities.

When you visit the site and it presents a login form, your browser should helpfully auto-fill the data you had explicitly saved for that purpose. The interaction should be quick and thought-free for the user. And, critically, should absolutely BREAK in a phishing attempt. The browser should be so completely unwilling to deliver credentials to a phishing site such that it makes her stop and think about why the thing isn't working.

This feature is your primary line of defense against phishing. It has to work. You are unavoidably less secure if the user can't depend on this feature working transparently and effortlessly under normal conditions.

And while this is primarily used for credential storage, it's also a secure place to put other secure data as well, such as payment cards, address, security questions, etc. Such additional data probably won't be site-specific, but should probably not auto-fill without prompting.

One option to rule them all

The problem here is that in many implementations, the autocomplete=false option controls both behaviors. Both the one you want to keep, and the one you want to kill.

Ideally, "secure" auto-complete should never be disabled. We're relying on this feature to add safety, so misguided site operators shouldn't be allowed to jeopardize that.

And ideally, "automatic" auto-complete should be disabled by default, to be enabled only for those rare conditions (if any) where you actually want the browser to re-use your input from other sites.

Improve this answer
11
  • 11
    I'm currently wrestling with the problem of keeping username/password autofill from activating when an administrator goes to modify another user's account. It's true that autocomplete="off" has lost much of its meaning, but there does need to be some way to designate that a page is not a login form.
    – Brilliand
    May 12, 2014 at 22:45
  • @Brilliand If it doesn't look to the browser like a login field, then it won't assume that it's a login field.
    – tylerl
    May 12, 2014 at 22:58
  • 5
    "Looks like a login field" is unfortunately a fairly broad measure - a username/password field combination as part of a (large) form for editing another user's settings seems to match that heuristic on every browser I've tried. Firefox respects autocomplete="off", but the only way I've found to get Chrome to treat a password field as not part of a login form is to add a second password field to the same form.
    – Brilliand
    May 12, 2014 at 23:15
  • 1
    @Brilliand Have you tried giving a non-standard name to these fields? usually a browser judges by metadata, like field names and properties.
    – Nzall
    Jun 12, 2014 at 10:04
  • 2
    I have a form where the user enters a data in a single text input and confirms using their password that the change should be done. Sadly chorme thinks its a username/password combo and automatically fills the form with the email and password. Nothing I did worked. I finally switched both to text. Password masking sucks anyways.
    – frostymarvelous
    Sep 21, 2015 at 18:31
43

When I do pen tests, I report an issue if a form field asks for sensitive data (e.g. a credit card number), is NOT a password field, and does NOT have autocomplete=off.

The rational is that browsers manage autocomplete for passwords quite sensibly: they give the user the option of whether to store the password, and (most) users can make a sensible decision.

However, for non-password fields the autocomplete behaviour is not desirable. If I let someone use my computer, they go to an e-commerce checkout page, and see MY credit card details autocompleted - that is bad.

Improve this answer
12
  • 5
    This is a good point. The specific bugzilla case is focused on username/password fields only (I didn't mention this in the question because I wanted a broader set of answers), but your input on credit card fields makes sense and is useful, thanks.
    – Manishearth
    Jan 26, 2014 at 21:21
  • What do you have to say about Lucas' answer, which seems to say that autocomplete=off should not be overridden by default even for password fields?
    – Manishearth
    Jan 26, 2014 at 21:23
  • 2
    @Manishearth - for online banking I probably would report "password field allows autocomplete" as an issue. But I wouldn't for something lower risk like a blog comment. system. I have pen tested many online banking systems (as have other guys here on SecSE), but I think they all had autocomplete=off on the login password, so I never had to make that call.
    – paj28
    Jan 26, 2014 at 21:27
  • But what if the person using your computer is you ? Which is the case most of the time.
    – Nicolas Barbulesco
    Jan 27, 2014 at 11:31
  • 17
    "if I let someone use my computer" - the moment you do that, isn't it a bit late to complain about security? Yes, there can be intermediate authorization steps - but really, if someone else sits at YOUR computer, LOGGED IN AS YOU, you are done for. The horse was pulled into the city, the moat is crossed, the gate is opened, the portcullis is lifted. Maybe you can hide your valuables in the dungeon...
    – Floris
    Jun 11, 2014 at 18:43
8

The reason browsers are ignoring autocomplete=off is because there have been some web-sites that tried to disable auto-completing of passwords.

That is wrong; and in July 2014 Firefox was the last major browser to finally implement the change to ignore any web-site that tries to turn off autocompleting of passwords.

Any attempt by any web-site to circumvent the browser's preference is wrong, that is why browsers ignore it. There is no reason known why a web-site should try to disable saving of passwords.

  • Chrome ignores it
  • Safari ignores it
  • IE ignores it
  • Firefox ignores it

What if I'm a special snowflake?

There are people who bring up a good use-case:

I have a shared, public area, kiosk style computer. We don't want someone to (accidentally or intentionally) save their password so they next user could use it.

That does not violate the statement:

Any attempt by any web-site to circumvent the browser's preference is wrong

That is because in the case of a shared kiosk:

  • it is not the web-server that has the oddball policy
  • it is the client user-agent

The browser (the shared computer) is the one that has the requirement that it not try to save passwords. The correct way to prevent the browser from saving passwords, is to configure the browser to not save passwords. Since you have locked down and control this kiosk computer: you control the settings. That includes the option of saving passwords.

In Chrome and Internet Explorer, you configure those options using Group Policies (e.g. registry keys).

From the Chrome Policy List:

AutoFillEnabled

Enable AutoFill

Data type: Boolean (REG_DWORD)

Windows registry location: Software\Policies\Chromium\AutoFillEnabled

Description: Enables Chromium's AutoFill feature and allows users to auto complete web forms using previously stored information such as address or credit card information. If you disable this setting, AutoFill will be inaccessible to users. If you enable this setting or do not set a value, AutoFill will remain under the control of the user. This will allow them to configure AutoFill profiles and to switch AutoFill on or off at their own discretion.

Please pass the word that trying to disable autocompleting of password is wrong, browsers are intentionally ignoring anyone who tries to do it, and they should stop doing the wrong thing.™

If you want your browser to not autocomplete items, then you should configure your browser to turn off autocomplete. No web-site should be forcing that preference on other users.

Improve this answer
8
  • 5
    What if you're developing an admin interface that allows an admin to set and reset user's passwords, but the browser keeps incorrectly filling out these fields with the admin's own password. That can cause serious headaches and needs a workaround.
    – Simon East
    Mar 2, 2016 at 5:21
  • 2
    "No web-site should be forcing that preference on other users." We're a HIPAA-compliant website and one of our requirements is patients who sign up for our studies need to manually enter in their username/password to verify they agree with the terms of the clinical trial they're signing up for. We definitely need to disable this somehow.
    – Juan Treminio
    Apr 14, 2016 at 18:22
  • 2
    @JuanTreminio That's the exact reason why browsers ignore web-site requests to disable password saving. HIPAA is wrong. On the upside, you can have your IT department configure the group policy settings on the kiosk computers on your premises to disable auto-filling. But you're not allowed to disable auto-filling of a user sitting at home. That's the end of it. Tell the security auditor to message me - we'll have a chat.
    – Ian Boyd
    Apr 14, 2016 at 21:24
  • 3
    @JuanTreminio Then do two things. 1) change the browser group policy on the kiosk computers you create 2) do not let anyone access from their own personal computer that is outside of your physical control.
    – Ian Boyd
    Apr 14, 2016 at 23:50
  • 2
    Regarding the case of an admin interface where you change another user's password. Why use a password field to hide that input? You will have to communicate that new password to the user over some other medium, which will allow any person looking over your shoulder to see the password anyway outside the admin form. And an admin shouldn't have people looking over his shoulders when administering user logins. And any manually entered password should be changed by the user at next login. Having a normal input field makes it clear that this is no place to enter a secure, permanent password.
    – NineBerry
    Jan 31, 2017 at 0:58
7

I've done several pentests for several banks and we always advice to disabling auto complete. The reason for this is that most users do not use a password manager and thus the password gets saved within your browser somewhere, plain text (some browsers actually do encrypt the autocomplete passwords, but that's only been done recently).

This is also adviced by the OWASP testing guide:

Caching of form fields is present in most browsers. For form fields containing sensitive information - like credit card numbers - autocomplete should be disabled using AUTOCOMPLETE=OFF attribute that can be used in every INPUT tag1. This feature will fail validation against current versions of HTML specifications, it's now supported by most browsers though.

As long as the sensitive information is protected, there is no problem. The biggest issue with this setting is when using a shared computer. The risk of having your information cached is quite significant and a less innocent bypasser could just steal your information. Remember that most users aren't as well educated as most of the people on here.

Now the bank can't actually verify if you are using your personal computer or a shared one, therefore the risk assessment on this deemed it better to disable the autocomplete feature.

Improve this answer
10
  • 6
    The OWASP page gives a password field as an example, however the text talks of credit card fields. What do you think of overriding autocomplete=off for username and password fields only?
    – Manishearth
    Jan 26, 2014 at 21:25
  • 1
    @LucasKauffman : "some browsers actually do encrypt the autocomplete passwords, but that's only been done recently" - which do not encrypt passwords? And per the "recently" - when did that change, and for which?
    – jesup
    Jan 27, 2014 at 8:06
  • 2
    @Manishearth : For users who don't use a password manager, does it add to their risk if low-security sites allow passwords to be saved? I.e. does typical user behavior when not using a 3rd-party password manager (especially a network-synced one) lead to reuse of passwords on multiple sites, allowing attackers to leverage a crack of low-sec site one to get access to banking info at site two? (Under the assumption that most re-use, especially if they need to use multiple computers/browsers that don't share a password manager.)
    – jesup
    Jan 27, 2014 at 8:11
  • 1
    @Manishearth I wouldn't enable it for credit card information either, I like the extra step. I do realize that this reduces usability, but the risk tradeoff makes it worth it for me.
    – Lucas Kauffman
    Jan 27, 2014 at 9:27
  • 3
    I see that the OWASP gives really bad advice — in addition to using the wrong words.
    – Nicolas Barbulesco
    Jan 27, 2014 at 11:23
-1

Everyone seem to forget that computers get stolen on daily bases, most computers run windows. You can change a users password without ever logging in on a windows computer.

How much damage do you think can be done by a stolen computer with all autocomplete information saved in the browser? And most don't even have a password protection for browser autocomplete so it does not make any difference if the data is encrypted or not when the browser fills in the data for all sites.

Already today frauds on facebook and twitter is common. Saved passwords are one reason for this.

And what happens if a CEO saves his passwords and someone steals his computer? This feature is to protect everyone from getting their accounts hijacked.

Improve this answer
4
  • 10
    IMO the physical security of your computer is your own problem. With physical access, evertyhing is lost, for example one could simply install a keylogger instea of stealing it.
    – Manishearth
    Mar 7, 2014 at 3:30
  • 11
    1. Some computers get stolen on a daisy. These should have adequate passphrase protection. 2. A CEO is not a system admin and breaking into his account should not have any notable security impact for the information system.
    – curiousguy
    Mar 7, 2014 at 6:38
  • 2
    If the user cannot store passwords in the (at least encrypted) password manager of their browser, they will store them somewhere else. In a textfile "passwords.txt" on the Desktop or on a piece of paper beneath their keyboard...
    – NineBerry
    Jan 31, 2017 at 0:51
  • You're advocating for the completely impossible idea of users memorising all of their passwords, but never writing them down anywhere, never making them trivial to guess, and never re-using them. This is impossible. 50 years ago people had 1 password. Now they have over 100.
    – speciesUnknown
    Feb 3, 2021 at 12:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .