Alex Smolen

Alex’s autocomplete rant


Apr 2, 2012

For security people who design user-facing security mechanisms (like me), there’s a tendency to adopt a “couldn’t hurt” attitude towards increasing security, especially when the externalities affect someone else. But when we pass off costs to the user in the form of decreased usability, it can make the system less secure.

Let’s take, as an example, the autocomplete attribute. It was introduced by Microsoft as a non-standard feature in IE5. It allows sites to specify that input elements should be exempted from a browsers ability to store data for easy re-entry.

If a browser remembered your credit card number automatically, the next user of that browser could see it, even if you had logged out. Somewhat scary stuff, and reasonable to restrict with a server-side attribute.

But passwords never autocompleted the same way as other fields. The browser prompts the user to store the password in the password manager. The designers of autocomplete somehow decided setting autocomplete to false should disable the user’s ability to store the password in the password manager.

The perceived threat is that users would store their password on a shared browser, and an attacker on that same browser would be able to access a user’s account without actually knowing the password.

I’m sure the original designers of this feature nodded in solemn agreement about this behavior. In time, countless web security scanners started warning when this field was missing, adding to their finding count and justifying their value. Go to any bank web page, and look at the password form in view source. Sure enough, autocomplete is off for the form or the password input.

If an attacker has access to my computer and active browser, they could install a key logger, reset my bank password through my still-logged in email account, or modify my /etc/hosts file to point to a phishing server and install a rogue CA to boot. Passwords saved in a password manager don’t make that much of a difference in this scenario.

Also, browsers prompt before remembering a password, and kiosks can be set to disable password saving. So now, the threat is an attacker who uses the same not-locked-down computer as me and accesses a website that I have explicitly authorized to remember my password. Compared to something like phishing, this is a non-scaleable and relatively worthless attack.

I believe autocomplete actually has a negative effect on security. If I have to re-type my password each time, I’m less likely to choose a difficult to guess or unique password. Since autocomplete won’t fill in on the wrong domain, I’m more likely to fall for a phishing attack. And, of course, it’s a pain, which means users have less patience for other potentially more important security mechanisms. Saving passwords in the browser is the layman’s 1Password or LastPass, and it’s a helpful security feature. People aren’t good at passwords, and disabling autocomplete exacerbates the problem.

The worst part is that people are failing PCI tests because they don’t have autocomplete disabled. In my opinion, this is an industry-wide standard being perverted to enforce ticky-tack non-vulnerabilities and make everyone’s life a little better harder. I hope that browser makers, security tools, and standards bodies rethink this feature, and stop supporting or recommending it.