I noticed a while ago that many security professionals advise their customers to use ‘autocomplete=off’ in the password fields of login screens. It also started to scratch an itch on me when my password manager never stored passwords for a few websites. And I started to look for opinions before forging my own.
Websites advising to disable autocomplete
A few blogs, forum posts and even stackoverflow advise to disable autocomplete on password fields. Owasp.org itself advises to prevent web browsers from caching sensitive data in the client side.
What are the advantages of disabling autocomplete
The two main advantages for the security are the following:
- Avoid caching sensitive data on client site (CC numbers)
- Avoid storing the password in an insecure and hackable client-site database
The first bullet is in my opinion completely legitimate. Some information, like credit card numbers, should not be remembered in the web forms, because there is nothing that can let the browser understand that this field is sensitive, that its content should not be stored unencrypted on the hard drive and shown in plaintext at the first occasion when the user types a few digits in a text box (and be victim of shoulder eavesdropping). However passwords are different. They have their own class of input box and browsers know how to manage them. I will come to this later.
The second advantage of that policy is that passwords won’t be remembered in the case the user’s computer has been hacked. That’s true in a few occasions, like when the user has malware on his computer or his laptop gets lost/stolen. I would respond that no software password management solution can really help when the end user computer cannot be trusted. In many case, malware can just wait for the user to type his password to steal it. To efficiently protect against malware, users should be provided a physical device to be used to authenticate and sign any sensitive operation. That’s the only working mitigation in my opinion, we use these in Belgium for e-banking and it’s working pretty well.
Now, let’s get started with the cons of autocomplete=off
The most problematic drawback of autocomplete policies is that they interact badly with password managers. Password managers are in my opinion the best we can do to work around the inherent insecurity of passwords : don’t remember your password, let your password manager do it for you (and better. And without writing it down in plaintext). When you’re setting autocomplete=off, you’re effectively opting out of all the advantages password managers provide to users, and which are specifically designed to avoid some pitfalls, like the stolen laptop scenario.
The policy hard to change locally: the security policy is completely at the control of the server, which means users don’t control how they manage the security of their credentials, unless their password manager willingly override the autocomplete attributes.
A big issues is also the consequence on the security of passwords chosen by users for these services. Let’s say that you have to choose a password for a web service. This password:
- Has to be >8 characters, including capitals, ciphers and special characters (i.e. hard to remember)
- Cannot be stored on your computer or on paper for further reference (i.e. has to be remembered)
- Cannot be shared with other websites
- Must sometimes be written on embedded devices like a smartphone
Tell me how I am supposed to fulfill these requirements if I need 20 websites daily to do my work ? (my password manager has an hundred of entries). It’s simply impossible. As a consequence, users are going to work around this policy and either choose a very simple password, or a somewhat strong password that is the same on all services. The password manager permits the user to store secure password on a per-service basis. Breaking the password manager exposes the user to all the other behaviors. The lack of good web password managers on mobile platforms is also one of the reasons for poor passwords (no caps, special letters, ciphers) and password reuse on these devices.
Password managers protect against phishing. Don’t believe it ? Just go on a website (phishing site) that has nothing to do with the legitimate website, and you don’t see the password autocompleting itself. This should ring a bell even to inexperienced users. They may not even know the password, and having to add a few steps in order to get the password will probably put distance between the user and the fisher.
Please note that if you combine this policy and at the same time disable copy and paste into the password fields (I look at you, Blizzard!), I hate you. Your policy enforces weak passwords instead of promote them.
In conclusion/TL;DR
You may have understood it; my biggest problem against the autocomplete=off policies is that they break password managers, which in my opinion are the best tool we have to manage the hell that are passwords. By setting this parameter, you opt out of password management and force the user free to use less optimal management techniques like weak passwords or password sharing.
What to do ? Maybe promote password managers. Let the user decide on the password policy. Do not rely on passwords alone but use strong authentication with hardware devices. Update password managers to ignore autocomplete=off, which may be the case on a few password managers (I tested firefox sync and keepass, they don’t have that functionality).
I will happily read anything you may have to add to this, especially if I’m wrong.
Totally agree.
I wish there was an option to disable “autocomplete=off” support in browsers. And if I input a CC number, I can just choose “don’t remember”.
Good point about password managers helping to reduce phishing, I didn’t think of it.
I totally agree with you. If autocomplete is disabled, users will tend to make up easy-to-guess passwords.
For me, this “autocomplete=off” recommendation thing from security experts is just a quick fix.
It doesn’t solve the real issue and as you suggested, it even makes it worse!!!
People: lock your computer while away from the keyboard. that will solve most of your/the security issues 🙂
I can’t live withour remeber password inside my webbrowser. It is addict!
Hi there, just FYI: The top stackoverflow-answer you linked to strongly advises *against* using autocomplete=off.
Snip: “It is the client’s decision if they want to save passwords or not. What is particularly irksome is that this attribute breaks OS X’s native KeyChain support. So, even though the user has stored his password in a secure file, and authorized themselves and the application to use it, the website still thinks it knows better.”
Some patch for FF?
It couln’t be so hard…
Hi “like your father”
I guess that’s what you need:
https://addons.mozilla.org/fr/firefox/addon/autocompleteon/reviews/
I wrote a very simple userscript to turn on autocomplete on just about every form in Firefox. You can find it here: http://userscripts.org/scripts/show/130513
You can use it through a plugin like Scriptish or Greasmonkey.
It also works in Chromium btw….
If you like it, rate it please! 🙂
I recently came across a situation where autocomplete=off was needed to avoid browsers filling in a form with some silly values.
On a domain, I have multiple forms, which include a password field. Some of those are ordinary login forms, which include a username field and a password field. For this form, autocomplete works great.
But a different form on the site is used to configure an integration with a different site. The only way this could be made to work was by having the user type in a password for that other site.
But when accessing this second form, the browser would automatically fill in username and password intended for the first form. If a user was to actually submit the form like that, this would actually cause an unintentional leak of credentials because credentials form one system was filled into a form intended for another system.
The solution was to use autocomplete=off on the second form. Being able to save the password for the second form would be pointless anyway, since once you had successfully entered it into the form once, you’d never need to do so again.
From a user perspective using autocomplete=off on the second form should actually make the site more userfriendly, because having a login form prefilled with the wrong password is worse than not having it prefilled at all.
My case may be rare, but it just goes to show that there are good use cases for autocomplete=off. I certainly agree that browsers should be allowed to store passwords in the usual case, because often that is the most secure solution.
Hi Kasper,
Very interesting case. What happens if you change the name of the password field (input type=”password” name”othersitepassword”), does the browser still mismatch the two passwords ?
I think the best for your use case would be to integrate with the other site with OAuth or similar web federation technology, that way you wouldn’t even have to deal with credentials from other services.
but I ack there are some cases where autocomplete=off could be useful, it should just not be the norm.
Safari (OS X Mavericks) has a setting for this. Part of its auto completion settings I have enabled storing passwords for autocomplete=off.
I just tested changing the definition of the input field to this:
Even with that change, the browser still automatically fills in the saved username and password. So it appears changing the name of the password field makes no difference, and the browser fills in the password as soon as it sees a form with a password field.
I agree some other authentication mechanism would be better. The other site does actually have their own homegrown solution, which is not quite OAuth but at least share some ideas with it.
We tried it, but had to give up on that idea as we realized that it was too complicated for the users to understand. (In part because the other site had not put much effort into their part of the user experience.)
Blog software ate part of my previous comment. I guess if I want to write anything about html, I have to use html entities instead of < and > characters.
The input field I tested was this:
<input type=”password” placeholder=”other site password” name=”othersitepassword”>
For what its worth, IE11 ignores autoComplete=off on password fields, and Chrome Canary offers a flag that does the same.
Vote for this bug to get it fixed in Firefox:
https://bugzilla.mozilla.org/show_bug.cgi?id=956906
The reason so many sites suggest disabling autocomplete is that some years ago there was a huge exploit where every browser could be tricked into divulging their stored passwords via some javascript trickery. This allowed any website you browsed to the ability to, in one fell swoop, drain all of your passwords out of the in-browser manager.
Yes, the browser makers patched that exploit. But a browser is a huge, complex, system, and so, to be on the safe side against future, undiscovered, exploits, the general recommendation was to set no-auto-complete on password forms, thereby preventing the in-browser manager from being utilized. The premise was, if no passwords are stored in the browser, you can’t be drained by a password-vampire bit of javascript.
This advice is still sound, and you should find a proper, external, password manager with which to manage your passwords. By keeping them out of the browser storage, you reduce the possibility of browser bugs revealing them to effectively zero.
Check out Password Gorilla: https://github.com/zdia/gorilla/wiki for one such password manager. They provide far more features and security than the in-browser managers ever provided.
As a website owner say you’re happy with the concept of users caching their credentials, there’s a couple of ways you can implement that.
Leave autocomplete=on in the browser, which is easy to do. The downside for me, is you have no control over how the browser treats that password and also it’ll store the password in either clear-text or reversibly encrypted format.
So if someone shares the machine or compromises it, they’re going to get all the users passwords (Which is a bad thing(tm))
I’d say that a better option is for the site to manage it themselves. If they want to have “remember me” style functionality, then implement it themselves.
Have a checkbox which sets a long lasting cookie value which can be used to log the user in. this approach gives them more control (they can remember the source IP and perhaps invalidate the cookie if that changes), they can control how long the caching can last for. And if the PC is compromised the attacker doesn’t get the password, but a cookie that can be invalidated without asking the user to reset their password..
I am not an expert, but based on my experience I would venture that something more dangerous than autocomplete=off for password fields is autocomplete=on for secret question/answer fields.
You know what’s disconcerting? Logging onto a banking or other sensitive website, getting forwarded to a secret question/answer section which supposedly increases security, only to find that the answer to the question pops up immediately, as you’ve already answered it before. This security scenario would be even worse when the secret question is asked for the purpose of password recovery. Perhaps I’m missing something obvious, but to me this is a glaring security hole.
Actually there are a few problems when autocomplete is enabled that pose a big security risk.
I can tell you that i exploited a system once for work(using a persistent XSS) where the users would visit the site and just “read” the fields that the browser would happily fill in, so it would be too late for the user anyway.
In another example, some security conscious researchers just clicked on a malicious link (not intending to fill in the form) and their credentials were automatically available to the javascript by getting the field value!
And what do you think a MITM while disabling SSL would mean for your browser? Would it autocomplete the fields anyway? =)
I usually recommend disabling autocomplete everywhere, sorry but i DO want to control what goes in what input box and WHEN.
And if you are arguing about passwords, look at the keychains implementation that just fill the input *on request*.
Another big plus for password managers is that they can protect you from simple key loggers, since you don’t need to type the password manually.
Chrome: Tampermonkey [https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo?hl=en]
Firefox: Greasemonkey [https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/]
Both allow you to run customized javascript files on any page you want, automatically. I have solved this exact problem of removeing autocomplete=”off” on pages I wanted to store passwords for.
NOTE: Storing passwords is never secure…
So when a department of defence contractor is working from a hotel, for example, and the evil maid comes in while he’s in the shower. She should be able to go to his history and automatically log in and view potentially confidential or top secret information?
There are other scenarios….many others, where autocomplete of credentials is a very bad idea. Just because you can’t think of them doesn’t mean they don’t exist. Some people just need to be saved from their own stupidity and giving someone the option to bypass security controls for ‘convenience’ is NEVER a good idea….EVER.
I have a similar case with Kasper above, that autocomplete = off is actually needed. My current form in the admin area, gives the site manager the ability to create new users. No matter what, Chrome does fill the fields with the current user’s data, resulting in a bad user experience and confusion.
I also do not comply with the argument that Browsers Password Managers help users choose better and stronger passwords. I have a long experience training/supporting beginners or average users and even when they are given the ability to save their passwords, they do not think/create better passwords. They are still creating their easy to remember/guess passwords no matter what and in most cases they are still using the one and only password they feel comfortable with. So in practice this argument does not work. Only users that are a bit more experienced/trained are using such features the right way, but such users are already ready to use other more efficient ways to deal with their passwords.
Also the passwords stored in Browsers can easily removed with the clearing preferences, so even if a user has stored a stronger password in the browser, he can just remove it.
Overall I believe that the best way is to have users been trained since the biggest part regarding security comes down to each single user. So a quick button to save credentials in a browser just for the shake of speed does not help a lot to this direction, although I love to save most of my passwords in my keychain and have them autofilled in most of the websites I use daily.
Everybody, who’s sick of ignorant attitude of Chrome/Chromium developers toward this issue, please, go and star or comment on this bug in the tracker: https://code.google.com/p/chromium/issues/detail?id=375329
There is a use case here that appears to be missing. It’s actually one that I’m currently struggling with on Chrome for a site that I’m developing. In my case, the site I’m building has a form that appears after a user login that requests a password that is unrelated to the user’s account. However, Chrome insists on prepopulating this for with the user’s username and password. The fact that I as a developer can’t override the autocomplete in an instance where it’s completely appropriate to override is simply a pain in the ass that I shouldn’t have to deal with.
Furthermore, there are workarounds. There are always workarounds. They’re hacky and lead to poorly built web applications, but the idea that simply disallowing a site to turn off autocomplete for a form is actually going to stop a website from “turning off” autocomplete is naive. I completely understand if people hate a site for not allowing their browser to save their password. However, having a browser completely disregard something like this not only won’t fix the problem, but it promotes poorly constructed, hacky websites.
In general people who use and create websites have a very poor understanding of security. Requiring a password with an uppercase, lowercase, number, special character, but not these 8 special characters is beyond stupid. Using a password without a mix of characters is stupid. Automatically saving all of your passwords is stupid. Using the same username/password for every website you’ve ever used is stupid. However, people do all of these things. The idea that a bank might want to add some more security is completely legitimate because if someone guesses that you’re password to plumbingforums.com is the same as usbank.com, they’re going to have to conver the difference when your account gets hacked. Is remembering a couple of passwords really that hard? Because if you were born before 1990, I know you used to have about 4,000 phone numbers memorized. You can do it, you just need to quit being so lazy.
In short, openness is always best and everyone needs to trust one another a bit more to do what’s best in addition to people in every corner to pull their heads out of their asses.
Hello Aris,
Generally you are right and more over finally you “won” and Firefox now ignores autocomplete=off almost entirely. However in my opinion they made it even worse than it was before.
You web-site has “autocomplete=off” then Firefox will allow password to remember in password manager however it will never be autocompleted. So normal users will be just forgetting that they have credentials stored in their browser and that’s ever worse than not storring them.
In my opinion “signon.storeWhenAutocompleteOff” option must be disabled by default and user should have an option to enable it and not vice versa. This is especially important for corporate environment when you have a single account/password for many services and storring them in Browser without encryption (wich is default and most if users do this) is a security issue.
Best regards,
Stanislav
You gave two reasons for disabling autocomplete and said that only the first was legitimate. In fact they are both illegitimate because browsers DO have a method for recognizing CC numbers. It is called the Luhn algorithm. Firefox for example will refuse to autocomplete a number passing this check even for a field that has autocomplete on.
Amen brother. Also annoying, when site authors disable paste in password fields, requiring us to disable JS or hack the DOM to get the password in there. Pfft.
Here’s a good case for setting autocomplete off and stunting password managers…
We had a rash of people using password managers who kept locking themselves out of their accounts. You login and your browser stores your username and password as “joe123” and “password123”. What happens when you reset/change your password? We send you to a page with the username hidden (and possibly obfuscated) and a blank password field on the page. You enter your new password and, the browsers we tested with, didn’t understand that you just updated the password for “joe123” to “sandwich123”.
You come back next week to login and your browser autopopulates “joe123” and “password123”. Who do you get mad at? Yourself? Your web browser? Judging my the number of nasty-grams we got from people calling us idiots for screwing up their passwords, it’s the website/service they get pissed at.
@brian k: My browser recognises changes in passwords.
Sometimes I forget the password or just want to confirm that it is what I think. When the browser autofills it for me, I just edit the DOM on that field and change type=”password” to type=”text” and there is my password for all the world to see.
Gotta love the security there.
Are we forgetting the obvious other uses for input fields, such as a chat / messaging application?
if a website asks for your password it means it asks for you. not for anyone that had the chance to use your computer and easily pretend s/he is you (key loggers are not on the easy side)
yeah passwords are not the best solution but for now we need to cope with it.
however my solution is pretty simple. no messy fake fields, no advanced tricks that you can not be ensure to work everywhere.
DISABLE username and password fields. then 0.5 sec after page loading enable them. browsers will not try to populate DISABLEd fields. and will not try to store credentials.
Hi, i think you are wrong! Disabling the autocomplete/autofill is not so bad at you said. In this article explain it: https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion
See for your self. I re-write the script of “vliegendehuiskat.nl” to invert the process of always activate autocomplete to disabled once for all.
(function() { var form, input;
form = document.getElementsByTagName(‘form’);
input = document.getElementsByTagName(‘input’);
if(form) {
for(i = 0; i < form.length; i++) { form[i].setAttribute('autocomplete', 'nope'); }
// to prevent the autofilling of form fieldsa; use a random value like "nope"! (don't use OFF);
for(i = 0; i < input.length; i++) {
if(input[i].type=='text') { input[i].setAttribute('autocomplete', 'nope'); }
// to prevent the autofilling of text fieldsa; use a random value like "nope"! (don't use OFF);
if(input[i].type=='password') { input[i].setAttribute('autocomplete', 'new-password'); }
// to prevent the autofilling of password fields; "new-password" should be specified! (don't use OFF);
}}})();
// ==UserScript==
// @name – Force AutoComplete always off.
// @namespace – https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion
// @description – Disable the autocomplete for all forms, texts and passwords fields.
// @why – Some data submitted in forms contain sensitive information like unique government identifier or
// credit card security code.
// @Note – Modern browsers will keep suggesting autocompletion:
// Firefox (since version 38), Google Chrome (since 34), and Internet Explorer (since version 11)
// So to really forcing the no-autocompletion is to assign a random string to the attribute.
// Since this random value is not a valid one, the browser will give up.
@ ealvarez The article you reference explicitly says that “It is important to know that if you turn off autocomplete, you are breaking the rule 1.3.5: Identify Input Purpose in WCAG 2.1. If you are making a website that should follow WCAG, you should use autocomplete with autofill.”
Disabling autocomplete is bad for security AND inconvenient for the user.
Everybody has a virtual Fingerprint, when you are working with that… it’s more easier to use, and the Machines have the control, about the security. 1 or 2 accounts i see it too so. Anybody can trey for him self and justice it.
Find your dream home with 99Asset – Your trusted source for Plots, Flats, Properties, and Villas in India. Explore certified real estate options today.
https://99asset.com/