Last Comment Bug 263387 - passwords should be stored for host+path and not just host
: passwords should be stored for host+path and not just host
Status: RESOLVED WONTFIX
[see comment #7 before adding a new c...
:
Product: Toolkit
Classification: Components
Component: Password Manager (show other bugs)
: Trunk
: x86 Windows XP
: -- normal with 21 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 283059 428709 430788 431686 432994 440024 443188 446138 448113 473975 480201 481750 483328 487227 494164 500260 540128 581543 1028755 1249237 (view as bug list)
Depends on:
Blocks: xss 373140
  Show dependency treegraph
 
Reported: 2004-10-07 14:43 PDT by Jesse Coddington
Modified: 2016-04-07 12:09 PDT (History)
53 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Jesse Coddington 2004-10-07 14:43:38 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1

The password manager should store username / password combinations for the
domain + directory and not just the url.

Reproducible: Always
Steps to Reproduce:
1. http://www.somesite.com/url/ (set a username / password and store)
2. http://www.somesite.com/adiffurl/ (set a username / password and store (same
username, different password)
3. go back to http://www.somesite.com/url/ (pulls up the adiffurl's username /
password)
Comment 1 Jesse Ruderman 2004-10-09 21:14:00 PDT
This change would break password manager on many sites.
Comment 2 Jesse Coddington 2004-10-11 07:16:11 PDT
(In reply to comment #1)
> This change would break password manager on many sites.

I agree.  But its better than using Firefox for one of the password urls and IE
for the other.  If i use Firefox alone, everytime i switch back and forth
between tabs and do something it would ask me for the username / password
combination.  Very annoying.

Plus since 1.0 really isn't out yet, I think that they could change this feature
and make it standard from 1.0+.
Comment 3 Worcester12345 2005-07-28 08:14:49 PDT
(In reply to comment #2)
> (In reply to comment #1)
> > This change would break password manager on many sites.
> 
> I agree.  But its better than using Firefox for one of the password urls and IE
> for the other.  If i use Firefox alone, everytime i switch back and forth
> between tabs and do something it would ask me for the username / password
> combination.  Very annoying.
> 
> Plus since 1.0 really isn't out yet, I think that they could change this feature
> and make it standard from 1.0+.

 1.0 has come and gone. WFM? Other?
Comment 4 David P James 2006-06-16 11:44:48 PDT
Mass edit: Changing QA to default QA Contact
Comment 5 Michael Wu [:mwu] 2006-07-16 22:22:17 PDT
Looks related to bug 234770 in associating logins w/ path.
Comment 6 Robert Chapin 2006-11-13 23:22:43 PST
(In reply to comment #0)
> 3. go back to http://www.somesite.com/url/ (pulls up the adiffurl's username /
> password)

See exploit report
https://bugzilla.mozilla.org/show_bug.cgi?id=360493

Robert Chapin
Chapin Information Services, Inc.
Comment 7 Justin Dolske [:Dolske] 2007-05-18 17:02:46 PDT
This change would cripple the login manager on many web sites. While it might add some security in some extreme edge cases, I don't think breaking the rest of the web is worth that.
Comment 8 Matthias Versen [:Matti] 2008-04-12 15:14:25 PDT
*** Bug 428709 has been marked as a duplicate of this bug. ***
Comment 9 threexk 2008-04-12 16:31:54 PDT
I disagree with the comment that this is only a security risk in extreme edge cases.  It is not uncommon for a domain to be generally trusted, but specific parts of that domain be malicious.  

For example you might have a popular site with user-contributed parts of the site (like a MySpace) that you save your password to.  However a user of this site puts up malicious code to capture filled-in form data.  If you end up at that malicious part of that site, your passwords will get stolen.

Aside from the security issue, this bug causes frequent inconvenience as above posters have noted.  It is very common for a domain to have multiple places with password forms.

My opinion is it would be better to associate passwords with URLs in the most specific fashion unless the user defines a more flexible context (e.g. through simple pattern specifiers such as example.com/site1/*, example.com/*).
Comment 10 Justin Dolske [:Dolske] 2008-04-25 12:17:22 PDT
*** Bug 430788 has been marked as a duplicate of this bug. ***
Comment 11 Justin Dolske [:Dolske] 2008-05-01 10:35:22 PDT
*** Bug 431686 has been marked as a duplicate of this bug. ***
Comment 12 Justin Dolske [:Dolske] 2008-05-09 08:19:03 PDT
*** Bug 432994 has been marked as a duplicate of this bug. ***
Comment 13 Justin Dolske [:Dolske] 2008-06-18 09:04:18 PDT
*** Bug 440024 has been marked as a duplicate of this bug. ***
Comment 14 Justin Dolske [:Dolske] 2008-06-18 09:04:54 PDT
*** Bug 283059 has been marked as a duplicate of this bug. ***
Comment 15 Matthias Versen [:Matti] 2008-07-02 09:43:17 PDT
*** Bug 443188 has been marked as a duplicate of this bug. ***
Comment 16 BruceBohlen 2008-08-22 05:51:45 PDT
(In reply to comment #1)
> This change would break password manager on many sites.

I don't agree: Opera offers the user a choice between storing the password for the whole site or for a specific URL. The same functionality should be possible with Firefox. (If you think that novice users will be confused by the distinction, set the default to "whole site" and enable the second option via some switch in the configuration, where an advanced user will find it...)
Comment 17 Jesse Coddington 2008-08-22 10:37:38 PDT
I agree with Bruce.  A few people stated that this change would break things, but when you import the current settings, default them to "whole site".  This would allow things to continue to work without any issues allowing new password to be stored as "whole site" or "specific URL".
Comment 18 Justin Dolske [:Dolske] 2008-08-22 11:39:14 PDT
No, the "breakage" is about saving a login on http://site.com/foo/, and then people not understanding why it's not filled in on http://site.com/bar/.
Comment 19 Jesse Coddington 2008-08-22 19:48:08 PDT
Yeah but if all of the current passwords get moved over as "whole site", then it would work for http://site.com/foo/ and http://site.com/bar/, while NEW entries into the password manager would get the option to save as "whole site" or "specific URL".
Comment 20 Mike Connor [:mconnor] 2008-08-23 10:58:40 PDT
You're assuming users will remember how they saved their passwords.  You're also assuming that most users will understand the implications of the choice.  Both seem to be poor assumptions.
Comment 21 Justin Dolske [:Dolske] 2008-09-01 23:33:05 PDT
*** Bug 448113 has been marked as a duplicate of this bug. ***
Comment 22 Justin Dolske [:Dolske] 2008-09-01 23:34:28 PDT
*** Bug 446138 has been marked as a duplicate of this bug. ***
Comment 23 BruceBohlen 2008-09-17 22:49:48 PDT
I'm assuming that any user who managed to find the option to enable the "specific URL" choice, hidden deep in the config, will be able to tell the difference between both options and not blame Firefox later. I'm not talking about novice users here, but this is a feature which more advanced users need.
Comment 24 Matt Jeffers 2008-09-24 15:07:53 PDT
I am not a professional programmer and have limited experience of security - which is probably why I can't see the problem! Why does the user have to be bothered by a dialog asking them to choose between storing their password as a 'Whole Site' or 'Specific URL' ?

Currently Firefox will present the associated 'whole site' password no matter where the user is within the site. This is considered a problem/bug by many here - including me.

To the best of my knowledge, most sites' basic authentication systems store passwords for the current directory or below (eg .htaccess files in Apache affect the current directory and all child directories unless another .htaccess file is present lower down in the tree). So all firefox has to do is store and present passwords following the same hierarchy as is normal within the majority of web servers. Doing this will present the most likely password for the specific URL and there is no need to bother the user with dumb questions.

The user is always presented with a dialog prior to the stored password being sent giving advanced users, with the addition of a suitable optional additional options pane, the opportunity to enter a more specific password - which can then be saved within the hierarchy - or delete the currently presented password and move further up the hierarchy to the next most likely password.

Please forgive me if I'm being dull. But I just don't see the problem.
Comment 25 FiFtHeLeMeNt 2008-09-24 15:24:31 PDT
This is indeed a major bug in FF3 , but seems users opinions are not counted here , some of my friends have stopped using FF and are back to IE because of this bug.
I should mention FF2 was working fine and everyone was happy with that , I don't know why anyone wants to change this behavior.
Comment 26 Ronny Standtke 2008-09-27 14:07:57 PDT
I have to join in here. I am administering both of the following sites:
https://lists.sourceforge.net/lists/admin/pauker-discussion
https://lists.sourceforge.net/lists/admin/nioframework-discussion

Firefox uses only one password for both sides and this drove me just crazy because half of the time login failed. Switched back to Konqueror for this sides just because of this annoying Firefox bug...
Comment 27 Ronny Standtke 2008-09-27 14:17:35 PDT
Please reopen the bug.
Comment 28 FiFtHeLeMeNt 2008-09-27 14:25:44 PDT
(In reply to comment #27)
> Please reopen the bug.

I agree , how can we request to reopen the bug ? I doubt if they even look at it when it is marked as RESOLVED WONT FIX !
Comment 29 Justin Dolske [:Dolske] 2008-09-27 14:56:28 PDT
No, I watch comments, even on closed bugs. But I don't any fundamental change to the issues since the decision was originally made to WONTFIX this.
Comment 30 Ronny Standtke 2008-09-28 07:33:36 PDT
An initial decision should not be set in stone.
If you notice some time later that your original decision to not fix this bug was wrong (because now you know that there are valid use cases that you broke and other browsers exist that do it right), is there any chance that you change your mind and reopen this bug and find a solution for the future?
Comment 31 Justin Dolske [:Dolske] 2008-09-28 10:07:57 PDT
Like I said, the issues haven't changed. I know this feature is useful in some cases, and that some other browsers support it.

The problem is that many sites don't have unique login pages, and there's no good way to handle that without adding confusing UI or breaking the site (see comment 18 and comment 20). For example, consider http://digg.com/section1/Some_Article and http://digg.com/section2/Another_Article. I can currently save a password on either page, and have it work on the other.
Comment 32 FiFtHeLeMeNt 2008-09-28 11:03:28 PDT
Hi Justin,
Thank you for your reply , I believe the ultimate solution for this problem is to add another button to password manager interface and change buttons to "remember for this page" and "remember for whole site" , then it will be a new feature which all other browsers miss and they will follow for sure ;) as always.
but ignoring this problem wont help.
Regards
Comment 33 David Zechiel 2008-09-28 11:16:11 PDT
I am really surprised that this has been marked as a "Won't Fix", as the problem is severe enough that I cannot use Firefox with certain applications.

The worse case is a site that requires a login/password for access, but also has online forms on other pages that require different login/password values for storage in a DB.  Even though those form fields have pre-initialized "value=" attributes, Firefox OVERRIDES those default values with the login/password used to access the site.  If you now submit those forms after changing one other field, the login/password fields will be changed underneath you.  It requires hitting "Reset" (if you have one on the form) to get the form fields initial values set to what they should be!

This behavior never occurred in FF2 and should be fixed in FF3.
Comment 34 Justin Dolske [:Dolske] 2008-09-28 11:57:45 PDT
(In reply to comment #33)
> Even though those form fields have pre-initialized
> "value=" attributes, Firefox OVERRIDES those default values with the
> login/password used to access the site.

That shouldn't be happening, and is a separate bug from this one. Probably already fixed on trunk as a result of bug 446109 or bug 327977. If you can reproduce with a Firefox 3.1 nightly built, please file a new bug with debug output per https://wiki.mozilla.org/Firefox:Password_Manager_Debugging
Comment 35 Worcester12345 2008-10-01 09:12:22 PDT
(In reply to comment #32)
> Hi Justin,
> Thank you for your reply , I believe the ultimate solution for this problem is
> to add another button to password manager interface and change buttons to
> "remember for this page" and "remember for whole site" , then it will be a new
> feature which all other browsers miss and they will follow for sure ;) as
> always.
> but ignoring this problem wont help.
> Regards

Sounds like a good idea to me.
Comment 36 Jesse Coddington 2008-10-01 11:39:42 PDT
Agree with #32.
Comment 37 Simon 2008-11-21 09:16:16 PST
i can say the same thing like #25.

i have looked at the password manager config file where the system is the following:

(sub)domain (not path!)
name attribut of input tag eg. "username" <input name="username" value="">
saved username
password field name
saved password
another (sub)domain (not path!)

so the password manager should ONLY fill the form with the username and password name matching!
This is not working as expected!

please solve this bug!
Comment 38 Simon 2008-12-09 08:44:22 PST
Can anybody of the dev team tell please, why this bug is in the status WONTFIX???

Is there any really good argument for that???

"This behavior never occurred in FF2 and should be fixed in FF3."

Please solve this bug!
Comment 39 Matthias Versen [:Matti] 2009-01-16 09:43:23 PST
*** Bug 473975 has been marked as a duplicate of this bug. ***
Comment 40 Ronny Standtke 2009-01-16 12:41:54 PST
If anybody still cares to listen to comments on this bug report I also fully agree with comment#32. Please implement a solution to this severe bug.
Comment 41 threexk 2009-01-17 00:19:09 PST
Several problems with #32:
1. If you distinguish "whole site" and "page" for the remember button, you should also do so for the never button.
2. Having both "remember for whole site" and "remember for page" buttons makes the password manager bar pretty busy (a question, four buttons, and lots of text).  I think this would really hurt the simplicity of the password manager, and be a source of annoyance and/or confusion, as insignificant as the change may seem.
3. The difference between a "whole site" and a "page" might not be clear to some users.

I propose the following, which I believe retains the simplicity of the current implementation without the problems of #32:
1. Change "Never for This Site" to "Never".
2. (Optional) Remove "Not Now" button.  Button is nonessential and redundant with "X" in bar.
3. Add "Options" button.  Options button has two drop-down settings: (1) Apply to www.example.com, and (2) Apply to current page.  www.example.com would be replaced with the domain of the current site.

The proposed options button is similar to the options button for blocked pop-ups.  By default, "Apply to www.example.com" would be selected, meaning that the "Remember" and "Never" buttons apply to the whole site, which is the current behavior.  So, there is no added burden upon the user.  Only when the user clicks the options button and selects "Apply to current page" will passwords be saved just for the current page.

Existing saved passwords would continue to apply to the whole site, as this is how the current implementation works.  In response to the concern in the first sentence of #20: It is not important that users remember how they saved passwords for sites.  Regardless, if anything, a user would assume his or her password was saved for the whole site, since this is the default behavior.

The text of the choices for the proposed options button -- "Apply to ..." -- could perhaps be improved.

A disadvantage to this proposal is that passwords could be saved for a specific page or a domain, but nowhere in between.  i.e., maximal URL specificity or minimal URL specificity.

One problem persisting from the current implementation would be that saving passwords for an entire site by domain is vulnerable to cross-site password-stealing attacks.  See #9, first two paragraphs.

Any thoughts?  Problems with this proposal?
Comment 42 Zertrin 2009-01-29 16:20:16 PST
(In reply to comment #41)
> 2. (Optional) Remove "Not Now" button.  Button is nonessential and redundant
> with "X" in bar.

I don't think it would be a good idea for the users that are new at FF. The text button has the advantage to be clear and concise simultaneously. And the X button don't take so much place on the bar...

Otherwise the other propositions are interesting, particulary the "Options" menu.
Comment 43 juan becerra [:juanb] 2009-02-25 15:52:35 PST
*** Bug 480201 has been marked as a duplicate of this bug. ***
Comment 44 Matthias Versen [:Matti] 2009-03-13 18:08:32 PDT
*** Bug 483328 has been marked as a duplicate of this bug. ***
Comment 45 Justin Dolske [:Dolske] 2009-04-15 22:54:53 PDT
*** Bug 481750 has been marked as a duplicate of this bug. ***
Comment 46 Justin Dolske [:Dolske] 2009-04-15 22:56:11 PDT
*** Bug 487227 has been marked as a duplicate of this bug. ***
Comment 47 Matt Jeffers 2009-04-16 02:06:53 PDT
I don't understand why the browser doesn't replicate the way most webservers store passwords as per my earlier post. It would seem to be the most reliable and logical method. Would this cause major security problems?

https://bugzilla.mozilla.org/show_bug.cgi?id=263387#c24
Comment 48 Al Brown 2009-04-16 05:47:08 PDT
How is 3.0 better for my security if I continue to use 2.0 due to its more sensible password behavior?
Comment 49 Mike Connor [:mconnor] 2009-04-16 11:16:25 PDT
Which behaviour is that?  We've never stored host+path.
Comment 50 johannes 2009-04-17 01:44:59 PDT
Can this please be fixed? It's annoying as hell! I agree completely with #41: Keep the current behaviour as default, but make it possible to change it for some domains. I don't care how deep you hide the option for that, but please make it possible for advanced users. Novice users need not ever see it and can happily continue to use the default behaviour. Where's the problem in that?!
Comment 51 Robert Longson 2009-05-21 06:59:51 PDT
*** Bug 494164 has been marked as a duplicate of this bug. ***
Comment 52 Johnathan Nightingale [:johnath] 2009-06-25 11:54:45 PDT
*** Bug 500260 has been marked as a duplicate of this bug. ***
Comment 53 gert_p 2009-07-21 09:04:00 PDT
The decision on this issue should be revisited, as the supportive arguments have become invalid and the need for this change has increased dramatically.

I agree with the proposed solution in comment 41. However, it would not introduce new issues, rather than keep old ones (which would give a lower severity to this change).
Comment 54 Matthias Versen [:Matti] 2010-07-24 01:28:40 PDT
*** Bug 581543 has been marked as a duplicate of this bug. ***
Comment 55 Nicholas Patrick (Peter) Solin Jr. 2010-07-24 10:35:06 PDT
If a change such as this will break the password manager, then with all major updates for software, a conversion should occur between the 3.x branch and 4.0 to have the user specify the subdirectory for each saved password, with the option of going to the URL to verify the subdirectory, or, because this change will be directory-dependent, have each password default to / (root) for each website without recursion (so that accounts not in subdirectories will not override subdirectories) and leave it to the user to fix, the latter of which easier for the developers.

Problems like this should be not only opened, but prioritized over insignificant things coming in Chrome 4.0, oh I'm sorry I meant Firefox.
Comment 56 Tim (fmdeveloper) 2011-08-20 19:50:45 PDT
*** Bug 540128 has been marked as a duplicate of this bug. ***
Comment 57 Nicholas Patrick (Peter) Solin Jr. 2011-08-28 21:21:20 PDT
If so many bugs are being considered as a duplicate of this, shouldn't it be reevaluated instead of "RESOLVED WONTFIX"?
Comment 58 Mike Connor [:mconnor] 2011-08-29 07:44:29 PDT
No one has really made a new argument that hasn't been made in this (and another, older version, also marked WONTFIX)

There are two different arguments here:

1) This would somehow make things more secure.  The short version is that it won't, because foo.com/bar and foo.com/baz are considered the same site, from security/access restriction, so I can just embed an iframe to foo.com/bar and read the autofilled password.

2) This option would make life better for the corner case where foo.com/bar and foo.com/baz are using distinct passwords, but the same username.  This is a pretty rare corner case, really, and I don't think anyone's made a compelling argument that it's worth significant effort, code complexity, and extra UI to support it.

The general criteria for reopening a bug is someone presenting a compelling and _new_ argument for why the decision should be revisited, not simply "some number of people have asked for the same thing."
Comment 59 guckindieluft 2014-06-02 15:05:15 PDT
I realize that the last comment on the bug was added about three years ago but I stumbled across this issue only yesterday. In my opinion, there is another aspect to this problem. Nowadays more and more people tend to have a dedicated machine on their local homenetwork that offer several services over a web interface. I have 4 such services running an the all have a user called admin... well for administration purposes. Well, long story short, I can not use Firefox to conveniently access these services for administration since the password for one service will overwrite the password of all the others :-/
Comment 60 Mike Connor [:mconnor] 2014-06-04 19:48:05 PDT
That's basically covered under #2. I've seen very little evidence that people are running multiple distinct services, with separate passwords for each, on the same host as a common practice.  It'd be a lot of code complexity to support it (since this would break a lot of the web if we made it default), and the benefit is for a corner case.

That said, there's _zero_ point to having separate passwords for each service if you're going to have passwords autofill, since as pointed out in #1 same-origin would mean they'd be able to target the other services if they were being malicious.  Just set them all to the same password and be done with it.
Comment 61 [:Aleksej] 2014-07-03 03:22:02 PDT
*** Bug 1028755 has been marked as a duplicate of this bug. ***
Comment 62 [:Aleksej] 2014-07-03 03:26:29 PDT
(In reply to guckindieluft from comment #59)
> dedicated machine on their local homenetwork that offer several services
> over a web interface. I have 4 such services running an the all have a user
> called admin... well for administration purposes. Well, long story short, I

You can make a dedicated domain name for each service.  Somebody mentioned using separate local IP addresses like 127.2, 127.3.
Comment 63 Henrik Skupin (:whimboo) 2014-09-29 02:36:53 PDT
Mike, given that this is marked as wontfix, what would be the solution in terms of the following situation. For managing our mailing lists we have an admin area like this:

https://mail.mozilla.org/admindb/mozmill-ci

I for myself have to care about different lists, so I would like to store the password in the password manager. Sadly there can only a single password exist for a host, and an already stored password gets overwritten. So I cannot access the admin area of the other list.

What solution exist for those cases?
Comment 64 wsh 2014-09-29 02:57:43 PDT
(In reply to Henrik Skupin (:whimboo) from comment #63)
> Mike, given that this is marked as wontfix, what would be the solution in
> terms of the following situation. For managing our mailing lists we have an
> admin area like this:
> 
> https://mail.mozilla.org/admindb/mozmill-ci
> 
> I for myself have to care about different lists, so I would like to store
> the password in the password manager. Sadly there can only a single password
> exist for a host, and an already stored password gets overwritten. So I
> cannot access the admin area of the other list.
> 
> What solution exist for those cases?

I patched mailman's admin login template as shown below. This makes Firefox to remember passwords for each list. Of course, built-in Firefix support would be better, but this is sufficient for me.

--- admlogin.html.orig	2014-09-29 11:46:36.000000000 +0200
+++ admlogin.html	2014-04-21 21:57:14.000000000 +0200
@@ -14,6 +14,10 @@
       </TD>
     </TR>
     <tr>
+        <td><div align="right">Fake login for Firefox to remember password:</div></td>
+        <td><INPUT TYPE="text" NAME="login" VALUE="mailman-%(listname)s"></td>
+    </tr>
+    <tr>
       <TD><div ALIGN="Right">List %(who)s Password:</div></TD>
       <TD><INPUT TYPE="password" NAME="adminpw" SIZE="30"></TD>
     </tr>
Comment 65 Victor Benincasa 2014-11-24 12:05:59 PST
+1 for host+path password management. Certainly there are ways to keep it accessible to all users and avoid confusion. Suggestion:

- If a new username was used in a particular domain, FFox stores it+path, but keep auto-completing on all paths (current behavior);

- If the same username with different password is used on another path, FFox ask to UPDATE the current user password or to STORE THE NEW PASSWORD only for this specific path.

There are many cases where it is useful, like service providers that offer multiple services on the same domain, with same username and different passwords, ex:

https://apps.serviceproviderx.com/webmail/
https://apps.serviceproviderx.com/controlpanel/
https://apps.serviceproviderx.com/emailmarketing/
https://apps.serviceproviderx.com/phpmyadmin/
https://apps.serviceproviderx.com/billing/
...
Comment 66 Gilmar Aleixo 2014-11-25 13:12:56 PST
Host+path would be great. It's a mess when you open pswd manager in search of one particular pswd and see dozens, with no clue about which one is that  you  need. Alternatively, I would be happy if I could associate passwords with tags or any other identification, as long as I could retrieve the pswd needed.
Comment 67 Worcester12345 2014-12-16 17:00:40 PST
(In reply to Henrik Skupin (:whimboo) from comment #63)
> Mike, given that this is marked as wontfix, what would be the solution in
> terms of the following situation. For managing our mailing lists we have an
> admin area like this:
> 
> https://mail.mozilla.org/admindb/mozmill-ci
> 
> I for myself have to care about different lists, so I would like to store
> the password in the password manager. Sadly there can only a single password
> exist for a host, and an already stored password gets overwritten. So I
> cannot access the admin area of the other list.
> 
> What solution exist for those cases?

I'd say do a new bug for just that specific thing.
Comment 68 Mike Connor [:mconnor] 2015-01-07 17:07:02 PST
Concur with comment 64, I think that's a bug in mailman.  Password-only apps are sort of broken, since how do you differentiate if the form doesn't?
Comment 69 Christopher Head 2015-04-14 21:33:55 PDT
(In reply to Mike Connor [:mconnor] from comment #68)
> Concur with comment 64, I think that's a bug in mailman.  Password-only apps
> are sort of broken, since how do you differentiate if the form doesn't?

I disagree: you have a password for each resource to which you have access—an unconventional access control mechanism, but not IMO one that deserves to be called *broken*—and you differentiate between resources by URL. If you believe password-only authentication to be sort of broken, could you please explain *why* it’s broken rather than making an unsubstantiated claim?
Comment 70 Oliver 2015-04-15 04:48:33 PDT
+1 for a decent *built-in* password manager. Using a third-party manager is no good/trustworthy option.

Just switched from Opera 12.16 and this really trips me up. I used Opera since versions 5.x and had Firefox only as a fallback option. Btw, Opera had this functionality from the outset and I cannot understand some of the decade-old comments stating that this change would break the password manager on many sites.

The longer you wait to fix this, the more websites may be affected. Alas, for SSL issues no one cares about breaking many sites, right?

In fact the Firefox password manager breaks many sites for me, because suddenly I am left with but one password per domain and username.

Of course one fundamental difference is that Opera had me perform a mouse gesture or press Ctrl+Enter in order to fill one of the saved credentials. However, even in FF I need to press a Login or Submit button, so Ctrl+Enter was still faster as it would already encompass "clicking" the respective button.

This is relatively easy to do, btw. Store the full base URL and use the domain to match first. Only a single password stored for the domain? Offer it. Multiple matches available? Offer a dialog with multiple choices.
Comment 71 David Lauri 2015-10-12 07:55:18 PDT
I see that this is marked as WONTFIX, but I'm going to leave a comment here anyway to say that I wish you would fix this.
Comment 72 Alexis Kauffmann 2015-10-16 08:28:52 PDT
(In reply to Mike Connor [:mconnor] from comment #20)
> You're assuming users will remember how they saved their passwords.  You're
> also assuming that most users will understand the implications of the
> choice.  Both seem to be poor assumptions.

You're assuming that every user is stupid. You're also assuming that, even if there are some intelligent users here and there, they should all bow their browsing habits down to stupid user's standards. Those are unequivocally extremely poor-minded assumptions.
Comment 73 Alexis Kauffmann 2015-10-16 08:31:15 PDT
(In reply to Justin Dolske [:Dolske] from comment #7)
> This change would cripple the login manager on many web sites. While it
> might add some security in some extreme edge cases, I don't think breaking
> the rest of the web is worth that.

This is a rhetoric exaggeration, This feature does not "cripple" anything. In fact, Firefox/Iceweasel are crippled by the lack of this basic feature.
Comment 74 Alexis Kauffmann 2015-10-16 08:34:23 PDT
(In reply to BruceBohlen from comment #16)
> (In reply to comment #1)
> > This change would break password manager on many sites.
> 
> I don't agree: Opera offers the user a choice between storing the password
> for the whole site or for a specific URL. The same functionality should be
> possible with Firefox. (If you think that novice users will be confused by
> the distinction, set the default to "whole site" and enable the second
> option via some switch in the configuration, where an advanced user will
> find it...)

This is logical. Non-technical users should be educated, not obeyed. Firefox/Iceweasel has been educating me all along since 2005, I don't see why this aspect cannot be subject to explanation, education, warnings, just like everything else.
Comment 75 Alexis Kauffmann 2015-10-16 08:37:03 PDT
(In reply to FiFtHeLeMeNt from comment #32)
> Hi Justin,
> Thank you for your reply , I believe the ultimate solution for this problem
> is to add another button to password manager interface and change buttons to
> "remember for this page" and "remember for whole site" , then it will be a
> new feature which all other browsers miss and they will follow for sure ;)
> as always.
> but ignoring this problem wont help.
> Regards

This is the logical solution.
Comment 76 Alexis Kauffmann 2015-10-16 08:50:57 PDT
> 1) This would somehow make things more secure.  The short version is that it
> won't, because foo.com/bar and foo.com/baz are considered the same site,
> from security/access restriction, so I can just embed an iframe to
> foo.com/bar and read the autofilled password.

One can also set up a fake Paypal website at http://paypal.xubkiuksjk.info and find a hundred imbeciles who will type their passwords there. Sorry, I cannot accept the "almost every user is an idiot and so everyone else should yield to stupid people's standards" argument.

> 2) This option would make life better for the corner case where foo.com/bar
> and foo.com/baz are using distinct passwords, but the same username.  This
> is a pretty rare corner case, really, and I don't think anyone's made a
> compelling argument that it's worth significant effort, code complexity, and
> extra UI to support it.

This is NOT "pretty rare corner case" for people who, like me, have to manage a website with multiple resources like a Wordpress blog besides specific systems for Online Survey, CRM, E-mail marketing, User Forums and so on. Need another example? Well, very ironically, I cannot use Firefox/Iceweasel to store passwords to the many "mozilla.org" subdirectories. Isn't that great?

> The general criteria for reopening a bug is someone presenting a compelling
> and _new_ argument for why the decision should be revisited, not simply
> "some number of people have asked for the same thing."

Oh, "many people want a feature" is not a "compelling argument" only in "popular democratic" countries like Cuba, North Korea and China. I think you would find yourself at home there.
Comment 77 Fadi 2015-11-02 08:39:54 PST
I host many instances of a web application on my local machine: one for each client and each being a slightly different version/customization than the other. Each instance is connected to it's own database which is a copy of the client's database at a certain point in time. I use this for debugging and testing purposes and custom development. And I imagine this is a fairly common scenario for developers.

http://localhost/HRSoftforCompany1
http://localhost/HRSoftforCompany2
http://localhost/HRSoftforCompany3

Since each website is connected to a different copy of the client's database, different clients end up setting different passwords for the main "hradmin" user. Imagine for 50+ clients. Password Manager is completely useless for this and many times I end up locking myself out. It's absolutely frustrating. This is just one use case. I'm sure there are many more. Firefox is my development browser of choice and I'd like to keep it that way.

If you are worried about breaking changes for other users then a simple suggestion would be to keep saving passwords per host as is but to add a configuration setting "password.per.url" (set to "false" by default so that the 'internet will not break'). This would allow users who face issues with this to change it to "true" so that they would be happy too. Is there a problem with that?

I might be missing something but I don't exactly see why this is such a big issue? Especially since it's being continually requested since 2004.
Comment 78 celkaprog 2016-01-13 00:46:41 PST
Hello
Or it should be work as the following:
http://url.com/path/path2
Firefox should search saved password for this domain+path (url.com/path/path2)
If found then autofill with that datas.
If not found then it should search saved password for the doomain(url.com)
If found then autofill with that datas.

Is it so hard in 2015?
Comment 79 Djak 2016-02-03 10:29:45 PST
Hi, 
I'd like to see this feature in FF too and I found this issue.
I only talk here about HTTP auth, not auto-filling HTML fields (but it seems pretty the same).

Anyone could please confirm/infirm these statements with actual behavior ?

I have some stored login and passwords for the URLs http://site.com/foo/ and http://site.com/bar/.
(Therefore in the manager, 2 login/pwd couples for http://site.com)

Each time I switch between both URLs, FF sends wrong value for Authentification field ?
Therefore:
1) There is one useless HTTP request/response ?
2) Server logs a wrong auth ?
3) I can easily get the auth field dedicated to http://site.com/foo/ from http://site.com/bar/ code and vice versa ?

If all true, the actual behavior seems _less_ secured than behaviors proposed in some comments ?

At least, is there any way that FF could autofill pwd field of Basic HTTP dialog box when we change the login ?
At this moment, we need to retype both login and password.
Comment 80 stann435 2016-02-18 02:02:36 PST
I use a domain which hosts 2 separate application. Login to first application is at:
http://site.com/application1
login to second application is at:
http://site.com/application2

My login credentials are different for both applications, but firefox sees these login forms as one. When I store my credentials on form 1 and try to log in with form 2, firefox is sending my login credentials for applicaation 1 to the application 2. 

THIS IS A SECURITY RISK. PLEASE FIX.

Not talking about the fact that in cases like this I'm not able to to use the "store credentials feature" at all, because I don't know if the credentials currently saved are for application 1 or application 2...

You could make the "per form storage" an option for a domain to make it backwards compatible.
Comment 81 stann435 2016-02-18 02:04:34 PST
You could make the "per form storage" an option for a domain, to make it backwards compatible...
Comment 82 Tony Mechelynck [:tonymec] 2016-02-20 11:29:16 PST
Most of the comments in the past 9 years are advocacy whines which don't advance the matter in any way; in fact their bulk makes developers _less_ prone to read them all in detail. I am tempted to restrict comments on this bug but I won't do it — yet.

See also:
• https://bugzilla.mozilla.org/page.cgi?id=etiquette.html section 1
• http://catb.org/~esr/faqs/smart-questions.html
Comment 83 Djak 2016-02-20 14:36:36 PST
Hi Tony, 
you speak about "most of" the tickets so I guess you read all and deducted that the rest was constructive.
Could you suggest something to do about this issue that seems legitimate and asked by users ? New ticket ?
A dev here said that more data was needed to reopen a ticket, that's e.g. why I posted and I definitively think that this issue need a check (security and user usage commodity) and that "most of" the whines here are funded.
Cya
Comment 84 Jan Sonntag 2016-02-21 03:19:52 PST
*** Bug 1249237 has been marked as a duplicate of this bug. ***
Comment 85 Mike Connor [:mconnor] 2016-02-21 08:50:49 PST
(In reply to Djak from comment #83)

Comment 79, if you're actually using HTTP auth, indicates that you're not using separate HTTP Realms.  That's an admin configuration issue, and has nothing at all to do with this bug.

In terms of everything else recent, please take a look at comment 58, specifically how same-origin means this proposal has zero real value for security.

If you're are hosting multiple applications from the same origin (scheme + host + port), you are already running in a insecure environment, with or without any change advocated for in this bug.  If it's the same origin, a compromised application can read cookies, embed the other app in an iframe and read the content (including the password form), and all sorts of other fun stuff which comes along with how same origin access works on the internet.

My advice to fix this entirely server side: Learn to use subdomains, and run each app on a distinct subdomain.  Or put everything behind HTTP Auth with distinct realms.  That's how you properly isolate apps from one another.
Comment 86 stann435 2016-02-21 10:11:10 PST
(In reply to Mike Connor [:mconnor] from comment #85)

You are right about the subdomains. But I think that the remember password functionality was made make the life easier in first place, and with multiple forms on the same domains it doesn't work.

I'm a web developer and have a lot of clients which have this issue. They often have eg an eshop and a blog on the same domain. The eshop alone has two sections, one for customers and one for admin. If they have the same username for each then the remember password functionality is messing up the credentials.

It would also be very useful if it would work on my dev server where I host multiple apps on the same domain for various purposes.
Comment 87 Djak 2016-02-23 13:11:41 PST
(In reply to Mike Connor [:mconnor] from comment #85)

Thank you Mike, after checking, the tested server effectively uses the same realms for each protected directories.
After configuration changes, the password manager does its job very well !
Comment 88 Bjoern Voigt 2016-04-07 12:09:03 PDT
If this change would break the password manager on many sites, then please allow a user-controlled white-list for sites which need this feature.

The functionality can look as follows (path 1 and path 2 are on the same host/domain):
- user saves password for path 1
- user switches to path 2 and the password is detected as incorrect
  - the user types in the correct passoword for path 2
  - old behavior: Firefox asks to save the password (this effectively overwrites the password for path 1)
  - new behavior: Firefox sees the different path in URL and asks the user about what to do
    a) user can save/overwrite password
    b) user can save an additional password (this also white-lists the host/domain; a warning can be displayed too, that this alternative may cause problems)
- of the user visits path 1 then password 1 is auto-selected
- of the user visits path 2 then password 2 is auto-selected
- if it's unclear for Firefox, which password should be used, a selection dialog with username/paths can be displayed

Note You need to log in before you can comment on or make changes to this bug.