Closed Bug 263387 Opened 17 years ago Closed 14 years ago
passwords should be stored for host+path and not just host
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+.
(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.
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: 14 years ago
Resolution: --- → WONTFIX
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/*).
(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...)
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".
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'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.
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.
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.
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...
Please reopen the 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.
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?
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.
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
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
(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.
Agree with #32.
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!
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!
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.
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.
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
How is 3.0 better for my security if I continue to use 2.0 due to its more sensible password behavior?
Which behaviour is that? We've never stored host+path.
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?!
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).
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?
(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?
(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?
+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.
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.
(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.
(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.
(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.
(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.
> 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.
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.
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?
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.
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.
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]
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
(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) 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.
(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…
I've been reading the arguments against this and most seem to focus on a few basic points: * Many feel that fixing this would "break" things. That's a weighted (and invalid) statement. Breaking implies the creation of a bug. Fixing this would not create a bug, it would remove one. * The detractors view a repair as breaking because it might confuse some people. Maybe. But it's far more confusing when you keep getting "wrong password" errors and don't know why since you definitely saved a correct password that FF previously remembered. It took me several days to figure out the origin of the problem. Confusion created by a bug requires repair. Confusion created by a repair only needs education. Why do we cater to the mentally lazy? * Confusion? Really? FF has a bucketload of features that even advanced users don't understand. FF puts them in a place where the people who do understand them -- and need them -- can find them. Why is this issue not worthy of such consideration? * Detractors view a fix as breaking because it adds complexity to the password dialog. It only adds complexity if the fix is applied to the password dialog. As noted, it donsn't have to be reflected in the dialog at all. But even if it is applied there, it doesn't have to be complex. Comment #41 has a simple and elegant solution. * Even putting the repair in the password dialog is neither complex nor confusing. It only requires a radio button or checkbox. Most dialogs have these and half of them make no sense to half the users. People who don't know what they do simply ignore them and leave them at the default. All FF needs to do is put that little question-mark-in-the-circle next to the button, which provides an explanation when you hover over it. * Besides, putting the repair in the password dialog is no more confusing than any other feature. The menus, preferences, dialog boxes, add-ons... indeed, pretty much any app a person uses, not just FF, is filled to the gills with options nobody understands. How long did it take you to figure out how to use your video editor or your rpg game? Whenever I use my tablet, I spend more time on Google searching out instructions than I spend actually doing anything. It never ceases to amaze me how people make it a priority to look for problems and confusion instead of solutions and clarity. This issue is a simple problem with a simple solution. The complexity and confusion is manufactured in your imagination. I use FF because of its funcionality. That quality used to make it a top choice in browsers. Has FF noticed that its popularity has plummeted while Chrome has skyrocketed? Have you wondered why? Please fix this.
Reported *13* years ago and I am still suffering with my development sites on my local machine. I end up creating my own MS Access db of passwords. You tell me is this really professional? Side note: Two major strikes now with Firefox: this and Firebug console being removed. How much do you guys care about your users and the popularity of your browser?
I second this request. The current behaviour that I can't save 2 passwords for 2 totally different services running on the same host is *very* annoying.
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) . 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.  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...
This has not been reopened despite significant interest in fixing it. Should a new report be created? As a longtime Opera user years ago who moved to Firefox, lack of this functionality has surprised me a few times.
@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.
See Also: → 1552759
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.