New Policy on Autocomplete Vulnerabilities

Views: 5276

Written By: Phil Purviance June 30, 2014

It's Time For Autocomplete Vulnerabilities To Die 

AutoFill (Safari/Chrome), Auto Form Fill (Firefox), AutoComplete (Internet Explorer). No matter what you call it, it's one of the most misunderstood browser features. Historically, it's been seen as a feature that places convenience over security. Today, I will explain how (when used properly) this feature gives users both convenience and better security.

For a long time, browsers have used this feature to save their users time when filling out forms or logging into websites. Around 2011, the W3C organization, responsible for setting HTML standards, added a definition to the standard that would allow web developers to specify whether or not a browser would attempt to remember and automatically fill in form fields. The name of the attribute is "autocomplete", and the only usable option for the setting is "off". Soon after, web developers would add this attribute to username and password forms. The use of the attribute grew even more once security vendors started citing the lack of this attribute on a username and password field as an actual security vulnerability.

Approved Scanning Vendors (ASV's) have been pushing the lack of the autocomplete attribute as a vulnerability on their scan reports since browsers started supporting the W3C specification allowing websites to do so. Due to differing opinions on when this feature should be used, we have come full circle and most browsers now completely ignore this attribute when set for login forms. One of the main arguments from the browser vendors is that customers will choose to use the browser that will remember their passwords, and the browsers that do not on certain web sites are "broken" IE Internals Blog Post. While this may be a good competitive reason to ignore this setting on certain forms, there are other benefits to users.

Lets talk about good password management for a second. It's well understood that people should not use the same password on multiple websites. This is because when one of your passwords is eventually compromised by a website getting hacked, it prevents the hacker from logging in to other websites with the same stolen credentials.

Unfortunately, the best passwords are made up of completely random characters, and its impossible for normal people to remember random passwords for the hundreds of online accounts they inevitably have. So, when people have similar passwords, it isn't just a matter of convenience, it's a matter of practicality.

That's where a good password manager comes in. While it's impractical to remember a random password for every website, it is possible to remember just ONE good, long, mixed character-set password. This is generally called a MASTER PASSWORD, and serves as the key to unlock a password manager vault. Within the vault is the username and password that you use to browse and login to online websites and applications. A good password manager will suggest random passwords for you when you create new online accounts, store them in the vault, and then automatically fill in your credentials when you go back to the website later. Google Chrome, Internet Explorer, Firefox, and Safari each have a password management feature, and there are a number of third party services like LastPass or 1Password available too. In each case, the password vault uses high-grade encryption, making it difficult for attackers to crack a good password.

In order for the far superior password management system to work, it must be able to remember all of your credentials, and be able to fill them into a website login box when required. Websites that attempt to enforce autocomplete="off" break the ability for users to use secure passwords. So, most password managers started ignoring the autocomplete setting by default, and now, the major browsers are following suit.

  • IE11 ignores autocomplete on login forms.
  • Safari 7 was introduced with an option to ignore the autocomplete setting. In Safari 7.0.4, the option was removed and it is now the default behavior to ignore it.
  • Firefox version 30 and higher will remember passwords with autocomplete=off, and requires the user to type in the first letter of the username to automatically fill in the rest.
  • Chrome version 35 ignores autocomplete on login forms.

So, why are ASVs saying this is a vulnerability, forcing your bank and online storefronts to change their code to add the autocomplete attribute? At one time, it sounded like a good idea to add it to a scanner, and the vulnerability went through a stage of proliferation where if one scanner didn't report it, it was seen as missing necessary vulnerabilities in the report. Times have changed, and scanners should no longer report this issue, since browsers are just going to ignore it anyway.

In summary: It's time to stop calling the lack of autocomplete="off" a security vulnerability. It's time for web developers to stop using it on login pages. It's time for people to start using a sophisticated password manager.

Poor Arguments

One of the main arguments for using the autocomplete attribute is for the scenario where a malicious person has access to another users computer. The attacker could visit a banking website the user belongs to, and steal the password that automatically is filled in. That is dangerous, but not when you look at the bigger picture. Any bad guy that has access to another users computer can use the opportunity to perform any number of malicious things. Instead of stealing a single password, they could install a keylogger to steal all of the users passwords (including the master password). It's hard to protect users that are already in a compromised situation, and it's better to remind them of these security issues than rely on software implementations that are easily bypassed.

Check out Troy Hunt's article "The Cobra Effect", where he details the practice of some banks actually disabling the ability for a user to paste a password into a login page. The rationale is that an attacker can steal a password that has been stored in the clipboard. While true, an attacker with access to the clipboard would also have access to the keyboard with a keylogger, or an on-screen keyboard with a screen-snapshot utility, or the password as it travels over the network. This kind of implementation inconveniences users without providing additional security. It's controls like that which irritate users, making real security changes more difficult to achieve.


Autocomplete isn't completely useless, and there are situations where a developer should have it set for security or usability reasons. An example of this is especially sensitive data or data that should never be entered more than once. Browsers will generally honor the autocomplete="off" setting in these situations where it should actually be used:

  • PIN Numbers
  • Social Security Numbers
  • Activation Codes
  • One-Time-Use Passcodes
  • Credit Card Verification Value (CVV2)
  • Nuclear Launch Codes (This one is straight out of the autocomplete specification. Hopefully there isn't a nuke somewhere that actually accepts nuclear launch codes from the web.)
Phil Purviance

Phil Purviance is a Senior Security Consultant at AppSec Consulting where he researches application vulnerabilities and performs penetration testing. Phil's body of work includes the discovery and proof-of-concept exploitations of critical security vulnerabilities, design flaws, and system weaknesses in hundreds of custom web sites and web application frameworks. Phil has presented his research at computer security conferences such as BlackHat, AppSec USA, Toorcon, and DevCon5. Phil also consults with clients and recommends helpful countermeasures that are useful to mitigate serious security vulnerabilities.

Phil received his Bachelor of Science in Business Information Systems from California State University, Chico. After college, Phil spent several years as an Enterprise Change Management Coordinator and a Server Systems Administrator before finding his true calling in the security field. Now he enjoys his work, where he can discover and exploit code flaws and weaknesses.

read more articles by Phil Purviance

© Copyright 2017 AppSec Consulting, All Rights Reserved