Firefox 3 Password Manager is a little TOO helpful
I was trying to fix a bug today, where saved usernames passwords in Firefox were showing up on other forms, in the wrong fields. Pretty simple, I thought - just change the names of the password fields so they’re different than the login page.
It didn’t work.
Apparently, the new Password Manager is designed to thwart security such as changing the names of the password fields, so the user has to enter the password. It looks for a field of the same name first, but if it doesn’t find one, it will put the password in the first type=password field it finds - and then puts the username in the text field just before that.
I really can’t see how this is good. But it’s not a bug. This was an intentional design decision by the Mozilla foundation:
Firefox stores passwords with this metadata:
domain usernamefield passwordfield username password
Then uses the usernamefield/passwordfield values as hints to find the appropriate <input> elements within a webpage by matching them to the “name” attribute.
Unfortunately this means that when a website redesigns and changes the un/pw field names, the effect on the end user is that the password is “forgotten”.
As a backup, when usernamefield/passwordfield fail to match, Password Manager should attempt to discover the password field manually, using a technique similar to what Camino uses.
While I understand trying to make things easier for your users, sometimes you can go too far. This, I think, is an example of that. It actually causes usability problems. See an example of a problem this can cause here. While this is a contrived example, it should be easy to see how a complex site could easily face these sort of problems.
Personally, I think Firefox needs to rethink this. It is not a good thing.
Tags: Firefox, login pages, mozilla, password manager, security
July 31st, 2008 at 12:05 pm
Additionally, in web-based applications that have any form of user management admin pages, a prompt appears for any page that has an input field of type=”password” on it. If someone’s job is to manage user accounts, they’re going to get pretty annoyed about having to deal with the prompt to remember the password each and every time a user record is edited! It seems the decision to simply apply password memory features to any and all forms that contain an input field of type=”password” was made unilaterally without any thought involved. Not all type=”password” fields are used for the entry of passwords. If the W3C and browser manufacturers want to adopt another input field type, say type=”masked”, to differentiate concealed input fields from actual password fields on actual login pages, then Mozilla can own the password field. But in the meantime, they need to change the way this works.
August 28th, 2008 at 10:46 am
Your example is not contrived. It is almost identical to all the user profile pages on all PHPBB boards and is already giving the forum administrators headaches.
September 6th, 2008 at 5:48 pm
I’m having exactly the same problems on a user management page. Apparently, this also happens with Chrome
September 6th, 2008 at 6:18 pm
And here is a workaround:
Put these two lines anywhere in the form html before the actual userid/password fields and they will consume the password manager fillins.
September 6th, 2008 at 6:21 pm
Sorry, my last post stripped out the tags (replace square brackets with angled ones:
[input type=”text” style=”display: none” /]
[input type=”password” style=”display: none” /]
September 7th, 2008 at 9:17 am
Michael, thanks for posting the workaround!
October 13th, 2008 at 2:54 pm
Unfortunately this workaround doesn’t seem to be working for me. If done just as listed firefox ignores them completely (will test on chrome shortly). If I put them inside an actual [form] then firefox fills in BOTH the decoy inputs and the ones I’m trying to avoid. This really, really, sucks since in my case I was using a hidden field as a spam trap and anyone remembering passwords was getting banned as spammers.
I’m not pleased with Firefox 3 at all.
November 26th, 2008 at 12:04 pm
I found another work around for this.
There is an attribute called ‘autocomplete’ and you can turn it to off on the password field and that will stop the the Password Manager from filling it out. The only thing with this is that it isn’t valid XHTML, so I add it with JS. The example below uses jquery, but I had to inline it, because if I put this code in a jquery DOM ready tag, the password manager will have already gotten to it and filled out the field.
[input type=”password” id=”user-password” name=”password” value=”" /]
[script type=”text/javascript”]
$(’#user-password’).attr(’autocomplete’, ‘off’);
[/script]
Replace square brackets with html ones
November 28th, 2008 at 3:17 pm
This problem is really annoying. Did someone send a complain to the firefox people? In the meanwhile here a simple work around:
Save two usernames and passwords and the password manager will not fill the fields because it doesn’t know which one to use. The secons username and password can be any fake string. Of course at the login time you must enter at least the username.
November 28th, 2008 at 3:44 pm
An other work around is to put in the FORM tag of the form where you don’t want the password to be filled the parameter:
AUTOCOMPLETE=OFF
January 14th, 2009 at 7:27 am
Thanks, I have a CMS I’ve been working on and this problem has been creeping up constantly. The autocomplete work around worked for me. Not sure if it made a difference but I also changed the field name of the username field and put the autocomplete=off in the password tag.
February 9th, 2009 at 1:50 am
Thanks for the help! The autocomplete=”off” works great in Firefox3. I was going crazy with this auto-filling at improper places last week. Thanks again!
April 9th, 2009 at 1:14 am
[…] le W3C mais qui peut être injecté de manière non intrusive en javascript comme suggéré dans un commentaire sur http://www.patternsofchaos.net (Ici avec […]