Turn On Autocomplete
The following is a possible new chapter to be added to Refactoring HTML in the accessibility section. I’m throwing this in fairly late in the editing process, so I’d appreciate any thoughts, comments, or criticisms you might have about this. In particular, I’d appreciate any cases you can think of where autocomplete is not appropriate.
For what it’s worth, I’ve pretty well convinced myself that usernames and passwords are not such a case. That is, autocompleting usernames and passwords definitely increases accessibility and usually increases security. I don’t intend to explain why it improves security in this chapter, but if anyone wants to disagree with that, I’ll explain why in the comments.
Remove autocomplete=”off” attributes where appropriate.
<form action="/login" method="post" autocomplete="off">
<p><label>E-Mail Address:
<input type="text" name="e1" autocomplete="off"/>
</label></p>
<p><label>Password:
<input type="password" name="p1" />
</label></p>
<input type="submit" title="Login" autocomplete="off"/>
</form><form action="/login" method="post" autocomplete="off">
<p><label>E-Mail Address:
<input type="text" name="e1" />
</label></p>
<p><label>Password:
<input type="password" name="p1" />
</label></p>
<input type="submit" title="Register" />
</form>
Motivation
Autocompletion helps users avoid wasting time retyping repetitive content. However, it’s especially helpful to physically impaired users (including the very young and very old) who have much greater difficulty typing than average.
Autocompletion also improves security in login forms by avoiding the need for users to write down passwords, or reuse the same password from site to site. Login forms that prevent users from using autocomplete are far more likely to be compromised by out-of-band mechanisms such a shoulder surfing.
Potential Trade-offs
Many webmasters believe that autocompleting logins is a security risk. It may indeed be so on a shared computer, such as one in a public library. However only the end user can determine whether or not their computer is shared. Users are always free not to remember a username or password, or to tell the browser to forget stored information, if they use a shared computer. That said, I do recommend that lab managers configure their computers to forget all stored information (not just forms but cookies, bookmarks, history, and other potentially private data) between browser restarts.
Mechanics
Search your HTML pages for autocomplete=”off”. This can appear on the form element or on individual input elements. When you find it, consider whether this is really appropriate.
Some forms really do expect different input each time. For instance, the main query field in a search engine likely doesn’t see a lot of repeated content from the same user, or at least not enough to make autocomplete helpful. Most users search for something different every time they visit. These forms may legitimately use autocomplete=”off”. Therefore you should not perform a blanket search and replace that removes all autocomplete=”off” attributes.
However, in the vast majority of cases, autocomplete="off" merely inconveniences users for little or no good reason. if you’re in doubt, remove it. The user never has to use autocomplete, but they should not be prevented from doing so by the server’s whim.
September 25th, 2007 at 10:57 am
This is nice if you’re building a website, but a web application is another matter entirely. I am specifically talking about admin interfaces, or CRM+ERP built using web interfaces.
September 25th, 2007 at 6:55 pm
>That is, autocompleting usernames and passwords definitely increases accessibility and usually increases security.
Yes, it really helps with accessibility, but therein lies a security risk- a virus could be able to get the files containing the autocomplete information, send it to its creator, and then be decrypted.
September 28th, 2007 at 5:20 am
It’s a little like trying to push the bubble out of a carpet. You can knock it down one place, but then it shows up somewhere else.
Assuming the browser uses strong encryption and secure coding practices, I’m not too worried about a trojan stealing the file. I am worried that reuse of passwords on multiple sites enables a hacker who gets to one site’s often unencrypted password database to then trivially guess the password for different sites. I don’t want Joe’s Autoshop to have access to my Amazon password. However if I can’t store the passwords in the browser, I use many fewer different passwords. These days almost every site or system I connect to has a unique password, but that didn’t use to be the case before browsers started autofilling passwords. It was just too much trouble to remember them all.
September 28th, 2007 at 11:01 am
How about the case of forgotten passwords, simply because the browser remembered a ton of them, one for each site, but finally
– my PC crashed
– new version of the browser didn’t faithfully copy
– I needed to badly access the site from a different PC
September 28th, 2007 at 12:42 pm
I agree with your argument that autocomplete is not necessarily a security risk, and it is often a poor choice on the part of web masters and web app developers to disable autocomplete (or to even null-out text fields using JavaScript) assuming that it increases security. It does not.
September 30th, 2007 at 10:17 am
As long as the web site isn’t handling transactions, such as Amazon or the home banking web site I use, I see no problem with autocompleting user names and passwords. The trade off is between a hacker stealing the user names and passwords saved by the browser from your pc and someone looking over your shoulder or stealing your user name and password you type in somewhere between the keyboard and the webserver.
September 30th, 2007 at 8:14 pm
I agree that forcing autocomplete off decreases security by forcing users to use fewer passwords.
I’m reminded of a story by one of the authors (IIRC – Dan Farmer) of Crack (the /etc/passwd brute force cracking program) – the author added the plaintext password file from a MUD site he ran to his dictionary file at a company he was the sysadmin … on the first pass Crack guessed the root password!
Also some machines e.g IBM/Lenovo Thinkpads are equipped with Fingerprint Readers+Software that fill in login forms (after a simple swipe of the finger) … even if the HTML requests Autocomplete Off – technically though this isn’t Autocomplete as it requires the user to swipe their finger. Also the IBM/Lenovo password manager isn’t restricted to only Web Forms – it supports Windows/NTLM, HTTP, VNC and other Login prompts as well.
November 19th, 2007 at 9:55 am
I definitely consider username/password autocomplete a security risk. While you are right, that browsers provide options to clear caches, password stores and the like, most users don’t know how to find the right buttons. Even if you have a “this is a public computer”-checkbox, there will be (a lot of) users who are like “oh no, it’s not public, it’s in my classroom/library/whatever”.
Hoogla Boogla
December 12th, 2007 at 6:16 am
I agree with Hoogla Boogla. The realistic fact is, that most users don’t know about the features of browsers. Most havent’ heard about cookies or history. They don’t understand why sometimes URLs/Names appear in a selection box and sometimes not.
For this reason, security must be defined from the standpoint of “dumb” (sorry…) users. Other users know enough how to configure their software to increase security. Security must be fool proof.
I think of another way to have secure passwords: changing passwords! There would be an algorithm how to create the password with operands oly known to the user. This way, traced passwords/keystrokes are invaluable as those passwords can’t be used a second time. It’s like a transaction number but with the algorithm and operands being easy enough for the user to remember. E.g. “dayOfWeek * monthOfBirth + ‘Hello’ “