Closed Bug 263387 Opened 20 years ago Closed 18 years ago

passwords should be stored for host+path and not just host

Categories

(Toolkit :: Password Manager, defect)

Product:
Toolkit
Component:
Password Manager
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: securifirm, Unassigned)

References

Details

(Whiteboard: [see comment #7 before adding a new comment])

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)
This change would break password manager on many sites.
Summary: username / password for url + directory not just url → passwords should be stored for host+path and not just host
(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+.
Blocks: xss
(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?
Mass edit: Changing QA to default QA Contact
QA Contact: davidpjames → password.manager
Assignee: bryner → nobody
Version: unspecified → Trunk
Looks related to bug 234770 in associating logins w/ path.
(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.
Blocks: 373140
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.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WONTFIX
Product: Firefox → Toolkit
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/.
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".
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.
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...
(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 !
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.
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.
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.
(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
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?
(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.
Which behaviour is that? We've never stored host+path.
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.
If so many bugs are being considered as a duplicate of this, shouldn't it be reevaluated instead of "RESOLVED WONTFIX"?
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."
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 :-/
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.
(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.
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?
Flags: needinfo?(mconnor)
(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>
+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/ ...
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.
(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.
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?
Flags: needinfo?(mconnor)
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.
You could make the "per form storage" an option for a domain, to make it backwards compatible...
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
Whiteboard: [see comment #7 before adding a new comment]
(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.
(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 !
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
Would it still break sites if the password manager saved the name and id of the form that submitted the login info?
Hi, a possible solution that won't break anything could be: - allow FF to save multiple user/pass couples for a site - if only one is found for the site, fill in - if multiple couples are found open a chooser to ask which username - fill in that and the relative passwd This does not solve the problem wih same user with different pass but it would be a step in the right direction. And I would appreciate it, as it would solve a problem with my users... Thanks, G
(In reply to Gian Piero Puccioni from comment #90) We already do this…
As documented multiple times here above, the same kind of situation can happen for multiple reasons, but here is a specific use case: an apache reverse proxy is used to access a bunch of applications on several hosts (virtual machines actually) with private ip addresses. https://proxy/app/host redirects to the correct vm ip and path. But as everything happens through proxy, firefox proposes all user/pass for every single app. Using subdomains would quickly become problematic since it makes the configuration of apache a lot more cumbersome, and requires an ssl cert for each subdomain. Is there a solution to this problem with current firefox ? Thanks, -- Rémi
a solution could be for firefox to handle wildcards in the host part of password manager, and give a semi-hidden possibility to edit that field to advanced users (there is already a module to do this). In my use case, I could distinguish the apps and hosts like this: https://proxy/app1/host1/* https://proxy/app1/host2/* https://proxy/app2/host1/* ... By default the password manager only saves the host part, so the current behaviour is not changed and the internet is not broken, but advanced users can add the required path as they see fit. Would this be a viable alternative ? Thanks -- Rémi
@William (comment #93), did you actually try that with Google's Chrome? Does it do the job properly? Also, I don't see how exactly this needs to be reflected in the password save dialog except for fringe cases. Saving isn't the issue, because all that may have to be added to password entries is the URI for which the credentials apply. The part that might need changing is when the password form gets auto-filled, though. Which is also, why I hold - as you - that there would be no breakage from actually fixing this issue.
@Oliver (comment #98) I don't recall now if I tried it in Chrome but I'm pretty sure I did. Even if Chrome is the same (I don't think it was), that only means they need to fix it too. I agree that it doesn't need to be reflected in the password save dialog. That's just one option. At any rate, I still prefer FF so I changed the respective logins.
@hobbes: I still can't see how it "breaks the internet" (or anything) if the password manager is _less_ generous about inserting my credentials anywhere. Also in your particular case you'd need no wildcard matching at all. All that'd be needed is for the base URL (the ones without the asterisks) to match the URL from the address bar and once that's the case the password manager would be okay to insert the credentials. All that has been asked for for well over a decade is for the built-in password manager (for lack of trust of third party password managers) to auto-fill based on schema://HOST/URI rather than based on HOST (or schema://HOST). Meanwhile I think that the fact that the password manager inserts a credentials without _any_ interaction from the user is the actual broken part (security-wise). After all it has transpired that there's a host of JS scripts which phone home with the auto-filled form fields (albeit so far only with hashes of these values in order to track users across domains) [1]. They'd be able to siphon the actual values and not just the hashes, though. Since this also affects at the very least the username from password manager auto-completions (which in many cases is an email address) how is that not broken behavior for a facility that is an integral part of the security of user credentials? Of course I could also simply use the same username and password everywhere, but that would be even more disastrous. Just to rehash what I think would neither break existing behavior (fellow programmers feel free to point out flaws!) nor be less secure: 1. save the URL with URI part (but without query and fragment) in the password manager for *newly* saved credentials 2. index the list by host name part of the URL also 3. if only a single set of credentials has been saved for a particular host name, go ahead and use the existing behavior * if multiple sets of credentials exist, pick the one matching the current URL best (i.e. saved URI should be contained in the URL from which the password manager is currently invoked) * alternatively (visibly) outline the fields which would get filled by the password manager and provide a shortcut that is required to have the password manager fill these fields. This way an interaction (and selection of the right set of credentials) is required for the password manager to jump into action. That's approximately the behavior that Opera's Wand had prior to "the purge". It's the most conservative option, since it will thwart attempts to siphon auto-inserted credentials via JS. [1] https://tech.slashdot.org/story/17/01/09/0521217/browser-autofill-profiles-can-be-abused-for-phishing-attacks
So if I understand correctly, a compromised device could serve scritps that have access to the content of other devices through the client's browser. Thanks, I didn't know that...
@richlv don't hold your breath. Fellow old-time (pre 12.x) Opera user here. I doubt this will be addressed as part of the core browser any time soon. Alongside Firefox I have used Vivaldi since it became available, but that inherits a similar flawed logic for the password manager as all other Chromium-based browsers (well, and Firefox), even though in many other aspects it's more of a spiritual successor to Opera 12.x (and earlier) than Opera versions 15.x and later are. However, earlier this year I found out that KeePass 2.x along with the KeePassRPC plugin and an extension called Kee (https://www.kee.pm) work very well together and that you as a user have very fine-grained control over the URL matching with it. By default the URL field from KeePass will be used, but each entry of the KeePass database (when editing) has a tab named Kee which allows to define rules for URL matching. It turns out to be highly flexible and seems to be a fairly secure and portable way to store ones passwords and have them available in ones browsers easily. KeePass, the plugin and the extension are all FLOSS and the versions I vetted didn't do anything fishy, which satisfied my requirements (as opposed to several commercial solutions with a similar scope). Maybe it also matches your needs.

+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://myitside.com/webmail/
https://myitside.com/controlpanel/
https://myitside.com/emailmarketing/
https://myitside.com/phpmyadmin/
https://myitside.com/billing/

Is @kizorr's suggestion also one that would break the browser usability?

Flags: needinfo?(dolske)

This isn't a case that's a priority to support as we don't want to encourage the behaviour of having different realms on the same subdomain. Please use separate subdomains if the password for a given username is different. There are many potential security issues allowing login theft from the different directories on the same domain.

(In reply to brunoais from comment #113)

Is @kizorr's suggestion also one that would break the browser usability?

Yes, because for the 2nd bullet the user now has to choose between Save or Update adding UI complexity.

Status: RESOLVED → VERIFIED
Flags: needinfo?(dolske)

I do agree with nikö comment #115, although his choice of words might be a bit inappropriate. Most web services nowadays like to do their own user credentials management. This is even more so in containerized deployments that is so popular today. When someone installs several such services and doesn't want to (or cannot) run his own dns server to create subdomains for them, the user of such services is confronted with inferior user experience. One could argue that the user should use the same password for all services on the same domain, this is not always convenient or desirable.

For instance I have a grafana server and a webmail service on my raspberry pi. These are totally independent and moreover the webmail uses the credentials of the imap server is proxies, which does not run on the same host. I think it would be great if firefox could manage the passwords for these services as independently as the services are. Using the strategy kizorr comment #112 suggests should not hamper user experience people expect and allow to manage passwords per service as needed.

I know that other browsers (~google chrome) don't have this capability either. This is a great opportunity for mozilla to give Firefox some added value it deserves and gain some market share again.

I'm surprised this (somewhat obvious) solution hasn't been presented yet:

Add an attribute to the login form html element, the attribute indicating the domain or sub-site the login / password is pertaining to. This should also be a CSS tag so that site-managers can add it to older apps which only support (or make it easier) changes to CSS.

For instance, on mysite.org/admin you might have:

<form class="login-page" action="/admin/auth.php" method="post" name="userlogin" 
  autharea="mysite.org/admin">
  ... 
</form>

For a CSS attribute, I propose (out of relative ignorance of mozilla css tag conventions): -moz-form-autharea

Alternatively, and perhaps for ease of implementation, the hint could be in the password field input element or part of its class.

<input id="wpPassword1" name="wpPassword" size="20" class="loginPassword mw-ui-input" placeholder="Geben Sie Ihr Passwort ein" tabindex="2" required="" autofocus="" type="password" 
  autharea="mysite.org/admin">

This would also solve related issues of several domains and hostnames sharing the same login credentials (when SSO is not used), such as bugzilla.mozilla.org and hacktheworld.mozilla.org.

Looking at WWW-Authenticate, a better choice for the tag is simply realm. Assuming there is no conflict there, I would recommend then it be associated with the <input type=password> tag:

  <input type=password realm="mydomain/application1">

and

  -moz-authentication-realm: mydomain/application

Apparently, I left my security cap in the shower today. The above solutions can end up being very very dangerous :(

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