Closed Bug 153986 (pwmgr) Opened 22 years ago Closed 15 years ago

Improve password manager heuristic so it doesn't break sites (multiple entries for same site; subject; mozillazine)

Categories

(SeaMonkey :: Passwords & Permissions, defect, P3)

Product:
SeaMonkey
Component:
Passwords & Permissions
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: asa, Unassigned)

References

(
URL
)

Details

(Whiteboard: parity-opera) 

See bug 85777 which should not have been closed. That was a bug misfiled on tech
evangelism that points to a real problem in the Mozilla and Netscape browser's
password management funtionality. 

This is the bug to make password manager not suck when visiting mozillazine.org,
devtrack, doctor (the new webtool for making changes to the mozilla.org website)
and other sites which don't conform to the not very smart heuristic that we
currently use to identify the fields that should be remembered.
Alias: pwmgr
*** Bug 95459 has been marked as a duplicate of this bug. ***
*** Bug 111679 has been marked as a duplicate of this bug. ***
*** Bug 109381 has been marked as a duplicate of this bug. ***
*** Bug 57923 has been marked as a duplicate of this bug. ***
*** Bug 110738 has been marked as a duplicate of this bug. ***
Related: bug 124070, Password Manager records duplicate identical logins at
mozillazine.
I hope this time somebody decides to do something about improving the heuristic,
instead of just brushing it off with a "WontFix" like before...
*** Bug 85777 has been marked as a duplicate of this bug. ***
*** Bug 124070 has been marked as a duplicate of this bug. ***
*** Bug 142520 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.2alpha
Target Milestone: mozilla1.2alpha → mozilla1.3alpha
*** Bug 166415 has been marked as a duplicate of this bug. ***
*** Bug 57923 has been marked as a duplicate of this bug. ***
*** Bug 174362 has been marked as a duplicate of this bug. ***
Another example of a site where the current implementation goes nuts is the
forums site at 

http://forums.battle.net/

There are three form fields relevant to this example.  The user name, the
password, and the subject of the post.  

Current behavior:

Every user/pass combination with a different subject is stored as a separate
login (all three fields are stored). 

Expected/Sensible Behavior:

Every user/pass combination should only be stored once regardless of other form
fields.

First of all, the subject of the post has nothing to do with login information,
so it shouldn't be stored in the first place.  If the intent was really to store
all relevant data in a meaningful way, user/pass/subject triplets should be
shown in the password manager identified with both user and subject, not just
user.  Otherwise, there will be many entries with the same user, with nothing to
differentiate them.

Admittedly this may be hard to do, especially if a web page designer
(maliciously or otherwise) designs a form where the user name and password
fields are out of order, are separated by other fields, are given unusual names,
or are otherwise obfuscated.

Nonetheless, the current implementation is not acceptable.  Either only store
the fields relevant to login information (which would be preferrable), or at
least differentiate the entries in the login chooser by showing all non-password
fields.  This would at least get rid of the problem of seeing 10 entries for
"JoeUser" without anything to distinguish one from another.
Reassigning to new module owner
Assignee: morse → dveditz
Status: ASSIGNED → NEW
Target Milestone: mozilla1.3alpha → ---
*** Bug 200653 has been marked as a duplicate of this bug. ***
I was the submitter of bug 200653, and I wonder if one thing I did may lead to a
potential workaround.  Specifically, I hacked the wallet file to remove the
entry for TITLE, leaving username and password.  This, however, leads Password
Manager to ask me if I want to save the relevant info every time I post there. 
I do not wish to choose "Never for this site" in response to that question, as
my intuitive belief is that that would remove the info I have already stored. 
My question is, for the case where some form info was available to be entered,
and was submitted unchanged, could PM exhibit one of the following behaviors:
1.  Do not prompt the user at all, or
2.  Prompt the user, but make a fourth choice available which would have the
effect of "Do not ask me this again for this site, but keep using the info I
have already stored."  This choice could be on the dialog but inactive when the
above criteria are not met by the form submission.


*** Bug 187076 has been marked as a duplicate of this bug. ***
In the past, i created a fake post on mozillazine where i left the "Title"
blank, then allowed PM to store the info. Then on my second post, I selected
never store PW from this site. This had the neat effect that the first info was
retained (and autofilled), but subsequent entries (with a Title) were not added
to the PM list. For some unknown reason, the ability to say "Never store PW's
from this site" was removed from mozilla (although the tab in PM still exists.

Suggestions:
1. restore the ability to say "Never store PW's from this site", or
2. if a site has ONLY clearly identifiable UN and PW fields, store the info.
3. IF there are more fields, bring up a dialoge:

   +-Password Manager ----------------+
   | Store login info for this site?  |
   | [x] UN      [                 ]  |  <-- default: ON
   | [x] PW      [                 ]  |  <-- default: ON
   | [ ] Subject [                 ]  |  <-- default: OFF
   | [ ] etc.    [                 ]  |  <-- default: OFF
   |               [ OK ]  [ Cancel ] |
   +----------------------------------+

Note: Adding to summary to avoid more dupes (apologies, if unwanted)
Summary: Improve password manager heuristic so it doesn't break sites → Improve password manager heuristic so it doesn't break sites (multiple entries for same site; subject; mozillazine)
It is know that the password manager heuristic can fail, but it is hard to come
up with a better heuristic. If anyone knows one, please explain it. It doesn't
need to be actual code, pseudo-code will do :)
A huge, complicated UI won't be acceptable. Neither will detecting the name of
the text fields. That will break on sites not in english.

For the record, what i understand of the code, wallet currently looks for a form
field of type password, and then takes the first text field of the form to be
the username. It does some other stuff, but that is not really understandable.
re comment #20: i do not understand, why this heuristic would save multiple
userid/password entries (but with identical userid/password) for the mozillazine
main page forums. When I go to preferences/privacy/passwords/manage.. several
identical lines are shown. Now the odd thing is that if I select different
entries from all those that look identical, the "Title" field of the form gets
filled in with different values. 
So obviously, the password manager not only stores userid and password, but also
the title, and since that is different for different posts, I get multiple
entries. The thing to do in that case seems to be to just ignore anything but
the first two fields. 
I think a better heuristic would be to find the first field that is a password
(invisible) field, then take the one preceding that field (not the first one) in
the same form - unless the password field is itself the first field, in that
case take the field after the password field. And take only these two :)

What is the idea behind remembering more than userid and password anyways?
Johann - you're assuming that Mozilla knows which field is which.  All it has is
the field types.  Mozillazine, for example, looks something like to Mozilla:

field1 (text)
field2 (text)
field3 (password-text)
field4 (textarea)

Mozilla doesn't know which fields are log in information and which fields are
not - it only knows the type of the field, not the content. AIUI, the current
code stores everything that's not a textarea.  The problem is how Mozilla can
work out which fields are username and password and which fields are something
else, given that the fields could be named anything (and in any language).

I do not think I was assuming that - I thought that is what we need a heuristic
for. Saving everything that is not a textarea is not a heuristic. Comment #20
indicated a heuristic that I think could be improved. Your comment indicates
that such a heuristic is not used.

Anyways - any heuristic will fail, the question is, are there heuristics that
will fail less often? And can we work out something so that web site programmers
can "help" mozilla to get it right without giving up too much flexibility? 

As I said in my previous post: there might be possibilities for heuristics like: 
UserID and password usually come one after the other (ignore checkboxes etc).
UserID usually come before password. Usually there is only one password field.
Even the "name" heuristic could be added - even if it fails for other languages,
it might improve the overall rate of getting it right, if there are ambigous
situations.

If password manager really saves *all* fields in the form, there is another way
to fix bad or erroneous behavior: add a dialog in the preferences/manage
password section that shows the list of fields stored and let the user check the
two fields that are really important. Then at least, the user has an option to
correct the bad behavior a-posteriori which is impossible now: either I live
with multiple entries or I have to disable that feature for the site alltogether.
As an afterthought, it might be good to at least *allow* page authors to give
Mozilla a hint which fields to store and which to ignore. For example, there
could be two names that will always be recognized as password and userid ( maybe
something like "MozRememberedPassword" and "MozRememberedUser". The damage in
the extremely rare case somebody wants to use these for something else is very
small, and the benefit for those who need to create forms with more than just
those two fields high. Obviously this is really something that should besolved
thought an additional attribute for the input tag in the W3 spec though.
The tendency is for bulletin board sites to use:
field1 (text) [ username ]
field2 (password-text) [ password ]
field3 (text) [ subject ]
field[4..n] (text or textarea) [ other stuff ]

One simple heuristic that would work on most sites I use is to just ignore
anything after the password field.

Suggested heuristic: 

- Make a list of known sensical field-names ("name", "password") in many
languages (DE: name, passwort) that are almost certain to yield a "hit" for most
sites. (To confirm the PW, also check for a PW-text field, so we don't splash
the users' PW onto the screen into a readable field.)
- If none of these work, THEN use the (ill)logic we have now.

After all, this is the PASSWORD manager (so UN & PW should suffice) and not the
FORM manager. (i've never really fully understood the way our form manger works)

Don't remember the subject (etc) in the PASSWORD manager.
That won't work. The list would be huge. And even then, it will miss lots of
cases. like 'id' for the username. So footprint will increase a lot, without
much gain. I don't need translations and variations of "username" in all kind of
languages i can't read.
And for my native language, dutch, it will fail in lots of cases. I can come up
with lots of names for the username field, which will not be in that list.

It will be much better to create a better general heuristic. The suggestion in
comment 21 makes sense to me. It is easy to find the password (type=password),
and then look at the closest normal input field. (afaik, firebird currently uses
this)

I still thing that looking for the 2-10 most likely candidates will most
accurately catch a majority of the sites. If that simple check fails, we can
then still use "heuristics" (witches brew). HTML code is always in english. I
bet many site developers could easily adapt to using mozilla's standard terms
(without even knowing it).

My list:
username
user name
user
user ID
user-id
userid
ID
password
pw
a quick list of the names of the username and the password fields from a few
sites i log in to:

sieveuid, passwd
pma_username, pma_password
Bugzilla_login, Bugzilla_password
S19_, S33_


All of those fail the list, and would pass the 'search password, username is the
field just before it' algorithm.
*** Bug 221842 has been marked as a duplicate of this bug. ***
Perhaps Mozilla could ask you(for sites with multiple login stuff) which parts
to keep(displaying the text of each) and then give you an option to stop it from
asking you for more passwords to this site.
A nice solution (for website authors) would be to use autocomplete=off on those
fields which shouldn't be stored, like "title" on mozillazine talkback.

But that doesn't seem to work: autocomplete=off has to be either on the form
itself, or on the password input field.
*** Bug 196127 has been marked as a duplicate of this bug. ***
*** Bug 202642 has been marked as a duplicate of this bug. ***
I've been trying Opera 7.5p3 for about a week, and its "wand" feature for 
remembering logins and passwords is great. It works on all kinds of sites that 
Mozilla's password manager doesn't handle well, including MozillaZine talkback, 
the Charles Schwab Customer Login, and Schwab BillPay. Any chance we could 
reverse engineer Opera's heuristics?
Whiteboard: parity-opera
Another site with this problem:

https://ssl.galileo-press.de/login/

the login-name and the passowrd-field will not be found. I hope, they fix the
code (72 errors).

Greetings, Markus
Product: Browser → Seamonkey
*** Bug 195690 has been marked as a duplicate of this bug. ***
Assignee: dveditz → nobody
Here's another situation where PM fails.  When you have multiple Mailman lists that you're managing, it only remembers the password for the last list you managed. You log in to Mailman list management at a page like this: http://your.domain.ext/mailman/admin/listname_domain.ext/ where all the lists on a given domain have identical URLs except for "listname".
QA Contact: tpreston
QA Contact: privacy
WONTFIX based on the fact that we have thrown the old wallet password manager out the door on SeaMonkey 2 development replaced with the same password manager backend as Firefox, see bug 390025.
Yes, we now have bug 222589 in SeaMonkey 2.0a3 and later, but with the now much smaller volunteer team we just can't take up our own development of things like password manager.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
Robert, we should at least name an open bug here which will make sure that we get this multi-dupe bug solved. Fine if this is part of Firefox and available in SeaMonkey. I suggest to reopen and dupe it to that bug. Thanks!
You need to log in before you can comment on or make changes to this bug.