Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

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

share|improve this question
3  
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 at 15:48
3  
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 at 21:04
    
@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 at 20:13
1  
@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 at 20:17
    
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 at 16:21

4 Answers 4

up vote 25 down vote accepted

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.

share|improve this answer
2  
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 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 at 22:58
1  
"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 at 23:15
    
@Brilliand Have you tried giving a non-standard name to these fields? usually a browser judges by metadata, like field names and properties. –  Nate Kerkhofs Jun 12 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 at 14:54

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.

share|improve this answer
4  
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 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 at 21:23
    
@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 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 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 at 15:27

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.

share|improve this answer
    
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). –  romkyns Jan 25 at 15:15
    
No not at all, as said recent versions of Firefox use a master password. –  Lucas Kauffman Jan 25 at 16:33
4  
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 at 21:25
    
@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 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 at 8:11

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.

share|improve this answer
2  
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 at 3:30
4  
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 at 6:38

protected by Community Jun 16 at 19:18

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.