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

nealmcb
  • 20,544
  • 6
  • 69
  • 116
Manishearth
  • 8,237
  • 5
  • 34
  • 56
  • 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 '14 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. –  Jan 26 '14 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 '14 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 '14 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. –  Jun 16 '14 at 16:21
  • Look closely at the question, `autocomplete=off` was only disabled for password fields. This is true for all three browsers. You should not be seeing any problem with security questions here, they use text input fields and should not be affected by any of the patches. – Manishearth Jun 16 '14 at 16:25
  • 1
    @Manishearth I'd guess that the problem lies where sites are using password type fields for secondary secrets. I have seen this behaviour ins some cases... – Rory McCune Jun 16 '14 at 16:36
  • @RоryMcCune in that case, don't use password fields :) Also, in that case they will still be prompted for saving the password-that-isn't. – Manishearth Jun 16 '14 at 18:36
  • @Manishearth sure in an ideal world but the reality is that sites do this for all sorts, I had one today do it for Debit card expiry dates and CVV numbers.. – Rory McCune Jun 17 '14 at 10:53
  • One problem with the current implementation in Chrome - it will always use autofill if the placeholder attribute contains the word Email. Even if the website is semantically asking for someone else's email. There has been a lot of user confusion on our site due to this. – Marc Hughes Mar 13 '15 at 14:31
  • When developing a backoffice and using a password input to change the password of another user in the database... We should never suggest to change the password of the current user ! And only the developer is about to know the context. – Loenix Oct 04 '21 at 14:05

5 Answers5

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.

Community
  • 1
tylerl
  • 82,225
  • 25
  • 148
  • 226
  • 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 '14 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 '14 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 '14 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 '14 at 10:04
  • @NateKerkhofs Yes, I've tried non-standard names. In this case, the browser seems to be judging by `type="password"`. (I actually have found a workaround by now - I put a hidden, dummy password field at the start of the form to confuse the browser.) – Brilliand Jun 12 '14 at 14:54
  • 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 '15 at 18:31
  • @tylerl, What about the problem with browsers inadvertently saving users' passwords in lanshops? The typical user will not notice it until they are doing their second login. Also, the typical user does not know how to fiddle with the settings to remove the saved password. – Pacerier Oct 01 '15 at 04:01
  • @Pacerier You don't base the core design principles for software like browsers around the uncommon usage cases like public kiosks. For things like that you take special precautions. For example, use incognito mode in your browser. Also, since you bring it up, don't log in to personal accounts on an untrusted computer. That's looking for trouble. – tylerl Oct 01 '15 at 05:05
  • @tylerl, Regarding *"don't log in to personal accounts on an untrusted computer"*, we're talking about users here. It happens *all the time*. And public kiosks are not "uncommon usage cases". They exist in many countries and are **extremely** common in some (e.g. Japan). – Pacerier Oct 04 '15 at 22:26
  • @Pacerier The fact that it's common in some countries doesn't make it *safe*. Around 60% of users also reuse passwords across sites, and typically around 1 out of 100 people use the password "123456". But the fact that it's popular doesn't make it a good idea. – tylerl Oct 05 '15 at 00:26
  • @tylerl, Of course it's not a good idea. My point is the browser **shouldn't expect** that its users are sysadmins. The base assumption of a product-for-the-layperson is that its users are dumb and unwilling to think. The base assumption is to ask the user *nothing* because when a user sees a "Yes / No" popup, we expect him to randomly select one. These comments are in reference to your suggestion *"When you visit the site and it presents a login form, your browser should helpfully auto-fill the data"*. Point is, the browser should **not** do that by default (without a setting change). – Pacerier Oct 19 '15 at 12:35
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.

paj28
  • 32,736
  • 8
  • 92
  • 130
  • 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 '14 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 '14 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 '14 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 '14 at 11:31
  • @NicolasBarbulesco then some people would want it to autocomplete and some people wouldn't. As present, the problem with autocomplete for non-password fields is that it doesn't offer this granularity. A browser option to override autocomplete for all fields is not such a crazy idea, but it should be hidden away in an advanced section and accompanied by a stern warning. – paj28 Jan 27 '14 at 15:27
  • 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 '14 at 18:43
  • +1 for the last statement. I didn't however like the first. Masking input is just a sure fire way to give users problems. – frostymarvelous Sep 21 '15 at 18:35
  • @Floris, You have never let a *friend* or *sibling* touch your computer? – Pacerier Oct 04 '15 at 22:28
  • @Pacerier - touch, yes. But never logged in as me. It is a basic security step. – Floris Oct 04 '15 at 22:35
  • @pacerier: how often do you let a friend/sibling touch your computer when they also would not be able to simply read the physical credit card from your wallet/purse? Given the extremely low cost of a stolen credit card and ease of tracking down the culprit, this seems like an almost theoretical attack. – Chris Adams Oct 10 '15 at 13:46
  • @Floris, @͏​Chris Adams. Looks like a culture difference then. Not letting your sibling/friend use your computer (yes logged in as *you*) for that 5 minutes when they wanna look up something is just plain odd over here. And regarding the "basic security step" you're talking about, in terms of paranoid security, it's a "basic security step" not to give them any touch access to the hardware. – Pacerier Oct 19 '15 at 12:08
  • If you let someone else use your computer why wouldn't you log them into the guest account? – shaunakde Dec 07 '20 at 14:37
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.

Ian Boyd
  • 2,125
  • 1
  • 21
  • 13
  • 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 02 '16 at 05:21
  • @SimonEast You certainly have the good use case. If you can propose a solution that a) does not allow a web-site to disable password auto-completion against the user's wishes, while b) allowing a web-site to disable password auto-completion when it's the user's desire, then you'd be rich! In the meantime, if the user doesn't want passwords to auto-fill, the user needs to change their preferences in their browser. – Ian Boyd Mar 02 '16 at 16:44
  • 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 '16 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 '16 at 21:24
  • 1
    @IanBoyd whether HIPAA is wrong or not is outside of our hands - we either implement its requirements or we place ourselves in trouble. – Juan Treminio Apr 14 '16 at 21:29
  • 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 '16 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 '17 at 00:58
  • 1
    On the subject of compliance, WCAG 2.2 has now added [Success Criterion 3.3.7: Accessible Authentication](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication), and setting autocomplete=off will insta-fail that criterion because it's a significant accessibility barrier. By failing to meet WCAG, you may be at risk of lawsuit under the ADA. – Andrew Ray Oct 14 '20 at 19:43
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.

Lucas Kauffman
  • 54,169
  • 17
  • 112
  • 196
  • Nice to have someone I might call an "insider" here. Suppose Firefox were to unilaterally throw away this option "by popular user demand", ignoring the opinions of banks. Do you reckon Firefox risks being outright blocked by banks in this case based on, say, UserAgent? (obviously circumventable, but not by non-tech users). – RomanSt Jan 25 '14 at 15:15
  • No not at all, as said recent versions of Firefox use a master password. – Lucas Kauffman Jan 25 '14 at 16:33
  • 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 '14 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 '14 at 08: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 '14 at 08: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 '14 at 09:27
  • 3
    I see that the OWASP gives really bad advice — in addition to using the wrong words. – Nicolas Barbulesco Jan 27 '14 at 11:23
  • 1
    @LucasKauffman Any answers on password encryption per above? – jesup Jan 29 '14 at 18:37
  • 1
    @NicolasBarbulesco not bad advice per se, just horribly out of date. – AviD Jan 20 '15 at 12:54
  • 1
    Working for a sizable financial services company, one of my concerns has not been defeating autofilling password managers -- I use them myself and was a contributor to pwSafe -- it's preventing autofill of the old password on a password change form. In fact, I was actively trying to defeat autofilling on the old password input field while making sure new password generation and remembering would be unaffected for the subsequent two new password fields. The solution to find fields based on type patterns is too broad stroked. – Rob_vH Sep 29 '15 at 17:00
-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.

Nisse
  • 33
  • 1
  • 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 07 '14 at 03: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 07 '14 at 06: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 '17 at 00: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 03 '21 at 12:58