Web browsers and saving passwords

Bank moves to close web loophole

The Morgan Stanley website allowed users to access account details after entering just the first digit of a credit card number.

The shortcut would only work if the account holder had set up the computer to automatically save passwords.

Password saving should not be available on financial websites and Morgan Stanley has now disabled the facility.

(via Bruce Schneier)

Upon reading the rest of the article, it becomes apparent that what they’re talking about is not a web site security vulnerability, but web browsers that save your passwords upon request. As most people know, if you ask IE to save form data (including usernames and passwords), it will auto-fill the form as you type. The first character of the data is usually enough for IE to find the appropriate information in the data store. Mozilla and its derivatives can also do this, but they require a master password to be entered in order to unlock the password database.

Web site developers can request that the browser not save login info for that site by using the autocomplete="off" attribute/value in their input fields, but ultimately it’s up to the client software to decide whether to respect that or not. IE respects it — I believe it was Microsoft who came up with this solution — and the Mozilla team, after some heated arguments, finally decided to honor it as well.

The problem as some Mozilla developers see it is that this attribute is a) non-standard, and b) interfering with basic functionality of the browser. They argue that their users should be allowed to make their own decisions about what sensitive data they wish to store on their computer, and the level of risk they’re comfortable with.

The argument for supporting this feature is that large numbers of people are incapable of making informed decisions about this type of thing, and that they should therefore be protected from themselves. The reasoning is that if the banks don’t let people save their online banking passwords, they don’t have to deal with the complaints if their customers’ accounts are compromised as a result.

For those who want to be able to work-around these restrictions, there’s a bookmarklet and an extension available. I haven’t tried either one, so I can’t vouch for how well they work. I’d like to see a preference added to Firefox that would allow people to choose whether or not to save these passwords, regardless of the wishes of the web site developers but unfortunately, before support for this attribute was originally added to Mozilla, banks dealt with this by sniffing browsers and denying access to anyone using Mozilla. This is even worse than not letting people their passwords, so it’s unlikely that this option will be added to Firefox, as it would probably result in the same thing. The extension above is probably the best option for this.

For those that choose to prevent password saving, or are required to by whoever they’re designing a site for, the current method of doing so, the HTML attribute/value pair, is problematic in that it isn’t part of the standard HTML specification, which makes it useless to anyone who wants to write W3C standards-compliant code. A better solution might be a meta tag that can be used on pages that ask for sensitive login information. Something along the lines of the following could have the exact same effect while still allowing your HTML to validate:

<meta name="autocomplete" content="off" />

I think both sides have valid points, but I tend to lean toward the first camp. Browser developers should write useful software and let people decide for themselves how they want to use it. Web site developers should not interfere with the normal operation of their clients’ software. Washington Mutual doesn’t want me to save my password in Firefox, but that’s not a problem because I wasn’t going to anyway. Speakeasy doesn’t want me to save my account maintenance password either. This is slightly annoying, but I rarely use their site so it’s not that big a deal to me.


chrisholland says:

setting autocomplete=”off” is incidentally a solution to get rid of this error that pollutes Firefox javascript consoles, whenever focus is switched on an input box:


I like your meta idea as more elegant, though you obviously would disable this feature for all inputs on a page?

I would suggest a somewhat more compatible alternative to set this attribute via unobtrusive scripting and DOM. Something along the lines of:


OR, one could add a reserved className to a given input element such as:

<input type="text" class="someOtherClass disableAutoComplete"/>

and then have a script at the bottom of the document that does something along those lines:

if (document.getElementsByTagName) {
	var inputElements = document.getElementsByTagName("input");
	for (i=0; inputElements[i]; i++) {
		if (inputElements[i].className && inputElements[i].className.indexOf("disableAutoComplete") != -1) {
		} //if current input element has the disableAutoComplete class set.
	} //loop thru input elements
} //basic DOM-happiness-check

setting this attribute via scripting should preserve HTML validation. Load the script from an external file to keep things nicer too.

Watcha think? :)

kchrist says:

I like your meta idea as more elegant, though you obviously would disable this feature for all inputs on a page?

An unfortunate side effect. That occurred to me too, but login pages usually don’t have more than one form on them. I’m sure this would work for the vast majority of sites out there.

I would suggest a somewhat more compatible alternative to set this attribute via unobtrusive scripting and DOM.

Interesting. Have you actually tested this? If it works, the first is probably the best alternative to writing invalid HTML. Ideally, one wouldn’t have to implement password manager disablers at all, but if forced to, this is probably the way to go. It’s a bit more work than a meta tag but its advantage is that it actually works with the current accepted method for doing this, unlike the meta tag thing I came up with on my first cup of coffee this morning.

chrisholland says:

i haven’t tested the second script, i’m lazy, but i’m 99.9% sure it’ll work as-is :) I like it better because it’s very generic and reusable. you could just stick the code in an external .js file which you call at the very bottom of any document which might need some disabling. just add the disableAutoComplete CSS class to any existing input element on which to perform the disabling. blam. ye done. or something :)