Closed Bug 112260 Opened 23 years ago Closed 15 years ago

Password manager silently overwrites form-supplied values

Categories

(SeaMonkey :: Passwords & Permissions, defect)

Product:
SeaMonkey
Component:
Passwords & Permissions
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: bartvb, Unassigned)

References

Details

Attachments

(2 files)

Testcase; first open the '1' file, then the '2' file.
734 bytes, application/x-zip-compressed
Details
Form testcase
769 bytes, text/html
Details
I'm one of the developers of www.phpbb.com We have a problem with the admin interface to alter a user the DB. To change the user the admin is presented with a form that contains: <input type="text" name="username" size="35" maxlength="40" value="JohnDoe" /> Our general login screen also uses a 'username' field (together with a password field). I've stored my username (BartVB) in for the site.. Now if I go to the user admin and want to edit a user the Form Manager changes the 'JohnDoe' value of the form to 'BartVB'. IMO that's NOT the desired behaviour. The Form manager should leave fields alone that have a VALUE set. Can make a testcase if wanted.
Reporter: Please always include which "Build ID" you're using. Thank you.
And please do include a test case with a detailed step-by-step set of instructions for reproducing. Unfortunately I don't understand what you are saying because form-manager never prefills a form unless you explicitly give it a command to do so.
Oops. Sorry, forgot the build number. It's the 0.9.6 release; Build ID 2001112009 If the Form Manager doesn't auto fill the form than this should be a Password Manager problem.. Can make a testcase but not now :D First need to get some sleep... Changed Component to 'Password Manager'. Haven't reassigned because morse is default owner of Password Manager issues too it seems :)
Component: Form Manager → Password Manager
Ok. Made a small testcase. See attachement or: http://www.vanbragt.com/misc/moz_pm_bug1.html and http://www.vanbragt.com/misc/moz_pm_bug2.html Fill in a username/pass on the first page and store it. Now when you go to the second page the prefilled username (JohnDoe) will be overwritten by the user/pass that are stored in the Password Manager. IMO this is not the desired behaviour.
So what exactly is it that you consider the problem? Is it the fact that password-manager is prefilling the second form with a value that it captured on the first form? Or is it the fact that it prefills a field that already had an initial value in the html? From the summary line I assume that you are referring to the latter. I would argue that that is correct behavior. An initial value is usually a suggestion from the website. But if the user changes that to a different value, then submits and saves, it's obvious that the user didn't want to take the website's suggestion. So on next entry to the page, the value that the user saved is the one that should be prefilled.
Indeed, it's the fact that it prefills a field that already had an initial value in the html.. It's not the same page in this case and websites don't suggest values out of nowhere.. Anyway IMO Netscape should leave the fields alone (including the password field) and should only fill it in during autocomplete or when you're on exactly the same page as where you saved the username/password. Current situation is very confusing IMO. BTW while creating the testcase I got to the point where Mozilla kept asking me which of 2 (identical?) identities I wanted to fill in as soon as I entered the page. But I thought there was a different bug about that point already.. Will do a search later :D
If we change the behavior, we should change it to "if the site suggests a username, only prefill a password if the user has saved the password for *that* username". I think that would be a reasonable change, although it would break sites that put the text "USERNAME" in the username field until you focus the field.
Sounds like a reasonable change to me. Don't know how the password manager handles these things but wouldn't it be possible to fill in the password when the users types a known username over the prefilled 'username' content?
Summary: Form manager overwrites fields with VALUE="username" → Password manager overwrites fields with VALUE="username"
By the way, http://evolt.org/ is the only site I know of that fills in username/******** in the boxes until you click on them. http://www.cnn.com/ does something similar with its search field. I find this practice confusing (and I'm sure it's irritating if you've disabled javascript), so I wouldn't mind if Mozilla changed in a way that encouraged web sites to leave these fields blank by default.
Target Milestone: --- → Future
confirming this bug (since it's a valid issue being discussed)
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 137823 has been marked as a duplicate of this bug. ***
Sorry I made a duplicate, but I'm glad to see someone noticed it too and explained it. To bad it hasn't been solved yet ;) It's there now for a couple of months and I saw it's still "new" and planned for the "future". What does that mean?
Status: NEW → ASSIGNED
*** Bug 140592 has been marked as a duplicate of this bug. ***
This just bit me badly. I've spent half an hour trying to figure why the hell the user details I had in a user maintenance page weren't being displayed, but _my_ details were always in there. Finally, I look at the source to the page and find the user's details are all there just fine, but at some point in the past (not today) I must have accidentally said 'Yes' to the save login details prompt, and all fields on the page (i.e. all details for that user) were saved. Mozilla is now quietly replacing the values my application inserts in there for the user record being maintained, and writing my own details in there instead. The current behaviour definitely has some non-obvious side-effects for people who are administering a database of users, complete with password fields. Even after I figured what was happening I spent some futile time wandering around in the "Form Manager UI" trying to clear the data out before I twigged that it was the "Password Manager"... The Architecture should probably be 'All' as this is happening here on Linux (1.0RC2), and presumably everything else since the original report was for WinXP. Also, the description could maybe change to something like: "Password manager silently overwrites all form-supplied values" Since the forms I am dealing with here have fields for name, address, phone numbers and lots of other things - not just username and password.
Changed description and OS
OS: Windows XP → All
Summary: Password manager overwrites fields with VALUE="username" → Password manager silently overwrites form-supplied values
It would be extremely nice (and terribly useful) if the auto-fill (both Password and Form) could be disabled on a page by some HTML meta tag, or by Javascript. Expecially in "web apps", it becomes a real pain if a user clicks 'yes' on a 'remember the values filled in'.
That metatag is the "autocomplete" attribute that can be put on either the form tag or the input tag.
Thanks a lot - it's a real relief. Is this attribute (and Mozilla behaviur with it) documented anywhere ? [ read: how is anybody supposed to know about it ? ] The autocomplete attribute is not in the HTML 4.01 standard: http://www.w3.org/TR/html4/interact/forms.html The only references I found are http://lists.w3.org/Archives/Public/www-talk/2000JanFeb/0017.html http://www.htmlref.com/reference/AppA/form.htm
It's documented somewhere on the MS site. You're not supposed to know about it because we discourage its use. However the financial sites insisted on it and blocked our browser until we implemented it.
This seems related / to be the same issue. I have the setting 'Preferences -> Privacy and Security -> Forms -> Save form data from webpages when completing forms' to OFF. However - if I save a password from a form, all other form elements but textarea's are also remembered. This is not expected behavior. A good example is the PHP bug database (http://bugs.php.net/). If I want to modify a bug, I will end up modifying it's subject/bug category/resolution state and even the reporter. IMHO the password manager and form saver should be completely separated from the end-user's point of view. They serve different purposes and are only related from an implementation point of view, especially since they can be turned off/on independantly. Further more - the current behavior is counter-productive and has nothing to do with online purchases, for which form filling seems to be integrated in the first place.
Sorry - build id: 2002101808.
*** Bug 147382 has been marked as a duplicate of this bug. ***
*** Bug 176642 has been marked as a duplicate of this bug. ***
*** Bug 152168 has been marked as a duplicate of this bug. ***
*** Bug 180679 has been marked as a duplicate of this bug. ***
Attached file Form testcase —
the 'autocomplete="no"' attribute does not solve the problem for me. I tried putting it both on the form tag and the input tag with no changes in behaviour Mozilla version: Mozilla 1.2.1 Mozilla/5.0 (X11; U; Linux i686; it-IT; rv:1.2.1) Gecko/20021210 Debian/1.2.1-3
Reassigning to new module owner.
Assignee: morse → dveditz
Status: ASSIGNED → NEW
I think there are some cases in which inserting automaticly and silently values in a form can be quite irritating and, if not wanted or expected (like in this example) and thus not controlled, can be quite dangerous. Imagine an admin who changes a user profile and saves the form, not noticing that the user data is overwritten with his own name and password. If there's a "forgot my password" function, the user who has been overwritten gets the admin username and password. It would be more secure and convenient to me if the user had manual control over such autofill login mechanisms. Like an icon in the toolbar (next to print icon or so) which is highlighted if you're surfing on a page where password manager would be able to autofill the password. If desired, you click the icon manually, leaving control to the user. Such a click is not far away and not annoying IMO. A shortcut (like CTRL-something) would make it quikly accessible. This would be much more transparent to the user.
I would also like to add my support to the idea that the current behavior is invasive and causes user errors. First, if a field has a value tag, then the value tag should take precendence. Only if the field has no value tag or the value tag is empty should the browser consider _automatically_ filling in the field, although I personally don't think I would ever turn that on intentionally. Second, auto-fill should be under explicit user control, similar to how IE pops down a list of values that are known to have been filled in in the past. (Hey, IE isn't ALL bad -- it's just the competition -- plus you guys seem to be imitating more and more of IE's good features anyhow.)
I don't normally add semi-useless comments like "why isn't this fixed yet?" to bugs, but in this case I'm making an exception. I develop a PHP-based CMS and it's driving us mad. This bug was originally reported nearly two years ago. Fixing it should be a two line patch for whoever maintains this bit of the code. You only need to check to see if the input box has already got data in it before filling it. This is causing such seriously important issues in so many web apps that I'm marking it a 1.4 blocker. Many people will doubtless disagree, but please if you do consider the triviality of the fix, and the seriousness of the problem.
Flags: blocking1.4+
mozilla@almaw.com, please don't set flags if you don't know how.
Flags: blocking1.4+
i think this is a very bad bug, as it already took a long time for me searching for strange "password changes" in our web-based user administration. I would prefer the following solution: If values are supplied by a form, a messagebox should show up to ask if the user wants to overwrite the form-supplied values with the values stored by the password manager. I wonder why this is marked as a "new" bug as the first bug-report is from 2001.
I believe the priority and severity of this bug should be increased dramatically. I also believe the developers should act a little more quickly to fix this bug (understatement). On the other hand, it might help if some of us were to try to locate the bug ourselves and offer a patch. That may be the mantra of a lazy or overworked maintainer, but if we want to get this fixed, perhaps we should offer some help.
this bug seems to be ignored ... why ? what can i do about it ? could anybody raise the priority ? this bug is marked "new" but it's first reported 2 years ago! (no, i can not provide a bugfix, as i am no "C"-programmer)
note that this has been fixed in firebird (bug 216395).
This wasn't fixed correctly in Firebird. See bug 218135.
I'm going to add me "me too" as well. I've developed a web interface for an embedded system. There are four userids, but only two of them can have their password changed. Here's a scenrio: 1) User logs in with one of the two userids that can't be changed 2) User selects "change password" page, so that he can change the password for another user 3) That page has the following tag: <input type='text' size='7' maxlength='7' name='user' tabindex=1 value='admin'> 4) However, instead of seeing "admin" in the "User ID" prompt, he sees his own password, "dev". 5) User then thinks that he can change his own password, even though he can't. Here's a more obscure scenerio: 1) User logs in with userid "dev" (one of the userids that CAN'T change its password) and tells Mozilla to remember the userid/password. User then logs out. 2) User logs in with userid "admin" (one of the users that CAN change its password), but does NOT tell Mozilla to remember the userid/password. 3) User goes to the change password page, that has this HTML in it: <input type='text' size='7' maxlength='7' name='user' tabindex=1 value='admin'> 4) User expects to see "admin" in the User ID: field, but instead sees "dev". Why? Because Mozilla was told to remember "dev" on the login page. This web page is completely different, but the input tag has the same name: user. Mozilla thinks the two forms are the same, so it overrides "admin" with "dev". Please fix this bug!
This bug will never be fixed. Still marked as new since 2001. I gave up using mozilla because of this bug. I can not recommend it to our customers because silently overwriting server supplied form data could cause lots of trouble in environments where more than one password is needed. Server supplied form data should never be overwritten by the browser (without confirmation), and no other browser but mozilla is doing that. Obviously nobody is interessted in fixing this bug, so i will stop any bug reporting from now on.
This is a horrible bug. It's bad that this doesn't get any attention. It could be that Mozilla has a lot of bugs that are far worse than this one, and the maintainers just haven't gotten around to it. That isn't encouraging. I don't have any knowledge of the internals of Mozilla, so I can't fix it myself. If we want this fixed, one of us is going to have to bite the bullet and submit a fix. I'm sure it'll be accepted.
*** Bug 175602 has been marked as a duplicate of this bug. ***
Note that a workaround for this issue is to uniquely name your form fields for login vs user administration. The browser will not overwrite form fields unless they have the same name.
*** Bug 262678 has been marked as a duplicate of this bug. ***
One of the comments and links in this thread suggests to use autocomplete="no". Most pages I found on this subject on the other hand suggest autocomplete="off". The former does not seem to work (tested on Camino20041021), the latter does. It's about time this tag became standardized and documented!!!!
Seems that Password Manager is still playing with the users nerves. If there is no option to set the auto-fill on at user request (see Additional Comment #28), then I suggest the "Undo" Feature. At user command the previous values would be restored.
Product: Browser → Seamonkey
I agree with most of the comments that this is a somewhat insidious bug. I have a basic form that requires a generic password, known to a group of people, to stop casual users from altering data. The password is just for the form, and not related to any username. One of the fields on the form is "Author". When editing the data, the "Author" field is pre-supplied by the form. However, Password Manager assumes that the "Author" and "Password" fields are linked, and fills both in, overwriting the form-supplied field. This is not the desired result. In my case may be able to get around it by supplying a dummy "username" field on the form - to fool Password Manager. But before I recognised the problem I overwrote existing data a number of times. Very dangerous if you are not aware of it. In my opinion, form-supplied data should absolutely take precedence over Password Manager. Often it is supplied by a database, and should not be changed. There are some cases when this might cause hassles - ie when the form supplies an initial value that is expected to be changed. But most sites would just supply a blank box in that case. If the form doesn't supply data, then perhaps Password Manager can fill it in. But even that may cause some issues. I haven't thought it through.
I'm experiencing the problem described here: http://drupal.org/node/433
It's been 3 1/2 years, will this ever be fixed? Sounds to me like the only reason it's not being fixed is that some people want this behavior for those annoying websites that put initial throwaway text in login fields. If that's the case, then why not just add an option under the "Save Passwords" options to "only auto-fill blank form fields", or make it a setting in one of the user config files like user.js.
I've tried added AUTOCOMPLETE="OFF" to my form tag, but it doesn't seem to do anything (using Firefox 1.0.6 on Windows XP). How do you get this thing to work? Currently I have to use Internet Explorer whenever I need to administrate users, 'cause unlike Firefox, their password management system actually works correctly.
For those following this bug, Bug 270558 appears to be similar, almost to the point of being a dupe. I see this behavior on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 (looks like 1.5 didn't fix it).
Assignee: dveditz → nobody
Bug 270558 is the equivalent bug for Firefox. This bug is for Seamonkey.
When will this bug will be corrected ?
This bug appears to be fixed in Firefox 2. I was able to reproduce it in 1.5 but not 2. Can anyone confirm?
Ooops. I just understood Jesse's comment. It is fixed in 2, just not in Seamonkey I guess.
(In reply to comment #54) > *** Bug 309312 has been marked as a duplicate of this bug. *** > I still have this problem with the last seamonkey. But I never had this problem with firefox. It happens on a page using javascript to modify the password for an account. Here is an extract of the code used : >function EditUser( pass_text, pass_value, boite_text, boite_value ,loginid) >{ > var pass = prompt(pass_text,pass_value); > if(pass) > var folder = prompt(boite_text,boite_value); > if((pass)&&(folder)) > top.BAS.location = >'?action=edit&pass='+pass+'&folder='+folder+'&loginid='+loginid; >} > <input value="Edit" onClick="EditUser('Nouveau PassWord :', 'my_password', 'Nbre >de boite?', '1','42');" _base_target="BAS" type="button"> When clicking on the button, the current password should appear in a dialog box, to allow it to be changed, instead of that the dialog box doesn't even appear and the password is crushed with another linked to the website url...
QA Contact: tpreston
This problem of silently overwriting password fields that have a "value" defined is still occurring in Firefox 3.0.4 (rv:1.9.0.4). I have a login page that defines "user" and "password" fields. I ask the Firefox password manager to remember these for me, and it does that well. However, there are other pages in my site where I am updating user records, which also have a "password" fields (and the value is set to "********"), so the HTML looks like <input type="password" name="password" value="********" size="20"> When I process this form, I look for the asterisks in the password to tell me if the user has changed this field. If they have, I update my database with the new password, otherwise leave it be. When rendering the page, Firefox is changing this value to the saved password that is used to enter the site. (The easiest way to see this is the number of asterisks is no longer 8). If I click on the "Reset" button, then Firefox puts back the specified value of all asterisks, but if the user does not know to do this, then the password is incorrectly written to the database. This only started happening recently with Firefox, but it really needs to be addressed. The password manager needs to remember the exact page that uses the password, not the domain.
SeaMonkey 2.0 is now using the toolkit password manager. The wallet code is now obsolete.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: