Closed Bug 369963 Opened 18 years ago Closed 16 years ago

Multiple master password prompts instead of an existing one being reused

Categories

(Core Graveyard :: Security: UI, defect, P2)

Product:
Core Graveyard
Component:
Security: UI
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 177175

People

(Reporter: zeniko, Assigned: KaiE)

References

Details

Attachments

(1 file)

Example call stack
20.51 KB, text/plain
Details 
Steps to reproduce:
1. Make sure that you've got a single saved password for at least one site (e.g. bugzilla.mozilla.org) and that you're using a master password to protect it.
2. Start e.g. Firefox and make sure not to enter the master password yet
3. Open the site you've saved the password for and let the master password prompt stay around.
4. Load the same URL a second time (e.g. by entering it into Start -> Run... in case Firefox is your default browser)

Expected result:
The new tab/window depends on the same master password prompt which is already visible (no reason to enter the master password more than once, is there?).

Actual result:
Another master password prompt.

This issue is particularly annoying when restoring multiple sites requiring password authentication through Firefox' SessionStore (cf. bug 348997) or a similar component. OTOH this works as expected when loading a bookmark group for which several passwords are to be filled in.
From bug 348997 comment #8:
> if I type from address bar quickly several pages on start-up,
> it will also ask multiple times for master password
I think this same bug is active on Thunderbird version 3 alpha 1 (20070326).

I have multiple email accounts, and I get one master password window for each account.  Previous (non-beta) versions of TB did not behave like this, asking for just one single master password, as expected.

BTW: Is this a duplicate for Bug 370375 (or vice-versa)?
QA Contact: ui
This problem has been around for nearly four years as documented by Bug 225710, though it is more noticeable now do to the Session Recovery capabilities.

There is actually a very simple fix for this.  Give the master password modal a name and use that name everytime the master password prompt window is displayed.  This will cause the same window to be used everytime instead of opening a new modal window each time. See http://developer.mozilla.org/en/docs/DOM:window.openDialog

BTW it is possible for the original modal window to get stuck behind the new ones without any way to get to it to enter the password or cancel it.  At this point the only option is to kill the Firefox process.
It looks like it could be done here:
http://lxr.mozilla.org/seamonkey/source/embedding/components/windowwatcher/src/nsPromptService.cpp#686

It would just require DoDialog to have another parameter with the window name and then it could be passed in from the PromptPassword function.

I would recommend though that a name be chosen at random at browser startup and then used through that session so that the name could not be spoofed by web sites.
(In reply to comment #3)
> There is actually a very simple fix for this. Give the master password modal a
> name and use that name everytime the master password prompt window is
> displayed.

Have you been able to test that fix? If so, would you mind attaching a patch for review? Not sure about possible security implications though.
Flags: blocking1.9?
OS: Windows XP → All
Hardware: PC → All
(In reply to comment #6)
> Have you been able to test that fix? If so, would you mind attaching a patch
> for review? Not sure about possible security implications though.
> 
Unfortunately no I haven't been able to code nor test this since I don't have the FF development tools installed on my PC.  The reason I suggested this fix is that I had the same exact problem with an addon I coded in that it would put up multiple "login" windows.  I fixed this by giving the window a name which causes the browser to reuse the same window when it opened a new "login" window.  Looking at the Firefox code I think it could work the same way.  

If it does not work, then perhaps a flag could be set when the password window is displayed and cleared when it is closed to prevent more than one window from even attempting to be opened in the first place.
Blocks: 356097
I wanted to submit a new bug but found this one :-) It looks that it describes my problem.

1. Set up the proxy (in my case squid) to require user/password login.
2. Set up a master password in Firefox (2.0.0.5 btw).
3. Enter any URL and check the "Remember password" checkbox for proxy user/password when asked.
4. Open a number of Web pages and enable the "save session" feature.
5. Close firefox and open it again.

Result: I get a large number of ask-master-password dialogs (in my case 7). I don't know why 7 since I had 11 opened web pages. Into every dialog I have to enter my master password, then the enter-proxy-password dialog displays and so on again seven times. Quite annoying.

I hit this bug also.
The way I run into it is that I have FF set up to open with the same set of tabs I had when I closed it.
Now if I have say a tab for Yahoo mail and one for Gmail open when I close
next time I open FF it will ask for Master Password for the first tab.
If I don't respond to that one quickly enough,
the second tab will ask for the PW as well.
Not only you get multiple prompts, but you cannot enter the password in the second popup window, because that window doesn't get focus when you're finished with the first password. You need to click that window with your mouse first to give it focus, before you can enter your password there.

At least in Firefox on Windows. Not sure about Linux or MAC.
While annoying, and we need to fix, we shouldn't block the release on this,
imo.  -'ing.  Please renom if you disagree.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Attached file Example call stack — 
Hmm, so I can reproduce this without needing a proxy or extension...

1) Save logins for two sites using HTTP auth [eg intranet.mozilla.org and totalfark.com]
2) Enable a master password
3) Enable session restore
4) Open each site in a tab, restart the browser.
5) When the browser starts up, you get 2 master password prompts.

The cause here is that we're processing events from 'inside' the dialog (so we don't block the whole thread). One channel requests auth, we put up a master password prompt, and then we handle the other channel requesting auth -- and put up another master password prompt.

I'm not really sure what the right way to handle this is... Add some kind of "master-password-entered" event, and make the callers who want authentication async? There seems to be a lot of code assuming this will all be synchronous, though, so that would lead to a layer somewhere grinding the two models together.
I can confirm this also still occurs for me when using the latest Release Candidat 
(In reply to comment #14)
> While annoying, and we need to fix, we shouldn't block the release on this,
> imo.  -'ing.  Please renom if you disagree.

Damon, did you mean blocking- or blocking+ ? You comment says "-" but the flag is set to "+".
Yep.  Indeed meant -.  Fixed.
Flags: blocking1.9+ → blocking1.9-
(In reply to comment #15)
> Created an attachment (id=289274) [details]
> Example call stack
> 
> Hmm, so I can reproduce this without needing a proxy or extension...

Have you seen comment #3?
Justin, the issue is not only a problem for the master password.

I have 39 windows con about 280 tabs. Some of the tabs are to password protected sites. Some of them to the very same sites.

When restarting the session, I get multiple (half a dozen) passwords prompts asking for the very same password: same domain, same realm, different URL.

In an ideal world, any page requesting a pass should "enqueue" the request (domain, realm, etc). Other entity would read that request and prompt the user if it doesn't already know the pass. When the user types the pass, it is stored for this session *AND* used to satisfy any other enqueued request.

So the user would introduce the password a single time, even if multiple pages request it at once.

Also in an ideal world there should be a option to only reload the contents of old tabs when they get focus. That way the tab with focus when the browser was closed would load quickly next time FF is started, but other tabs could still be viewed by switching to them.
Is this a dup of bug 338549 which *IS* blocking 1.9?
(In reply to comment #23)
> Is this a dup of bug 338549 which *IS* blocking 1.9?

In answer to my own question: No, this bug is about multiple simultaneous 
master password prompts.  Bug 338549 is about simultaneous password prompts 
for multiple different mailnews account passwords (not master passwords).  

Still it seems odd that bug 338549 should be a blocker, and not this one.

I'm not sure which versions/builds people are referring to but I thought this problem was fixed in a version of Firefox 2 (through my user experience). I've been Testing Firefox 3 and have found this bug to have re-emerged it's ugly head.

As detailed in one of this bug's blocks, this bug is particularly frustrating when a proxy server with authentication is being used.
This isn't fixed for Firefox 2. This branch is still affected.

This bug arises when you have at least two pages with http auth access open and restart Firefox. You have to input the master password twice. The count is raised if you have more tabs open.

(In reply to comment #19)
> Yep.  Indeed meant -.  Fixed.

Damon, this bug is not fixed! Or what does your fixed mean?

As additional note: If you bookmark this two pages inside the same folder, discard the master password and try to open the folder in tabs you also get the master password dialog twice. But the second one doesn't show any text. It's totally empty except the text field. 
(In reply to comment #26)
> (In reply to comment #19)
> > Yep.  Indeed meant -.  Fixed.
> 
> Damon, this bug is not fixed! Or what does your fixed mean?

He meant that he fixed the flag (it was accidentally set to blocking1.9+).

You also get multiple master password prompt when you open a page which uses the master password and in stead of using the master password dialog you change the username.
You can only fill in one master password dialog and make sure its succesfull, then you can close the others and continue business as normal.

Reproduce the bug/behaviour:

* Goto a page for which you use the master password.
* Change your username (or just use backspace) and see the ammount of diaglogs increase with every keystroke.
* Enter the correct password in the dialog box, cancel all other dialogs from the master password.
* Select the correct username, and proceed as normal.


Having session restore enabled and browsing on multiple sites which need user/password data this is really annoying when starting Firefox. The decision was that this bug isn't a blocker-1.9 but would it be possible to add it to the wanted-1.9 list? 
sure
Flags: wanted1.9+
I have the same problem over here, as a combined form of #10 and #15, plus I use so many proxies that I'm glad FoxyProxy exists. 

This bug is now a year old. 

Being too ungifted in C/C++/Mozilla internals to fix it myself, can I "grease" the debugging process with a gift/donation?
Blocks: 95397
(In reply to comment #33)
>
> This bug is now a year old. 

Actually closer to 5.5 years - see bug 177175
Blocks: 177175
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
Marc, please don't dupe a bug against (even) an older one which has more information inside. This one also has flags set.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
No longer blocks: 177175
Bug 356097 now shows the ill effects of having multiple prompts -- if you use a proxy (like in my corporate network) a session restore results in two prompts per tab. One for master password, one for proxy-- and the proxy one has to be type manually because the prompt comes up before the master password is filled in (meaning that firefox can't access your stored passwords yet) so it's bad. Very bad, and corporate-environment users who require this kind of security will be frustrated.
Flags: blocking1.9?
Standing by wanted1.9+ here.  This requires architectural changes that are not possible this late in the game.
Flags: tracking1.9-
Flags: blocking1.9?
Flags: blocking1.9-
(In reply to comment #40)
> Standing by wanted1.9+ here.  This requires architectural changes that are not
> possible this late in the game.

In a comment to this bug (or a duplicate; I can't find the comment right now), a developer mentioned that a dialog has a kind of "id" and it would be a simple fix to assign the master password dialog a unique+random id at startup and then use that id to open it. This way, the first page would open the dialog and all subsequent pages would block until the dialog is open.

This would look like a very simple solution. Can you please elaborate why this solution can't be implemented?

(In reply to comment #41)

> This would look like a very simple solution. Can you please elaborate why this
> solution can't be implemented?

Two problems:

1) It's not quite that simple, because there's no existing mechanism to take the result from one prompt and pass it to some other prompt. Blocking on prompting causes other problems, which is why that was changed in the first place (which unfortunately caused this issue as a side effect). There are also little details like not actually showing prompts for each request, and making damn sure we don't accidentally sling your master password off to some unrelated prompt.

2) Any change of this scope entails significant risk, and the prompt service code is known to be crufty -- there have already been unexpected regressions from changing it. We're far too late in the cycle for that kind of risk. Yes, I know that sucks.
I've opened Bug 426161 to improve the bug triage process in such a way that a bug like this one can't be moderated down early in the development process and then have it sleep until it is too late.
(In reply to comment #42)
>1) It's not quite that simple, because there's no existing mechanism to take
>the result from one prompt and pass it to some other prompt. Blocking on
>prompting causes other problems, which is why that was changed in the first
>place (which unfortunately caused this issue as a side effect). There are also
>little details like not actually showing prompts for each request, and making
>damn sure we don't accidentally sling your master password off to some
>unrelated prompt.

I don't think any blocking would be required.  If all the prompts used the same id, then any window that requested a master password prompt would open the same window.  If the prompt was already being displayed, then a requesting window would just use it.  The only issue I can see is that if a bunch of windows attempted to open a master password prompt, only one window would get the callback, but I'm not sure that's a problem thing since at that point the master password has been entered and the encrypted data unlocked.  

A more complete fix would be to add a notification mechanism to inform the windows when the password prompt has been dismissed, but the above would prevent the prompt from appearing multiple times and it shouldn't break things any more than they already are.


(In reply to comment #43)
> I've opened Bug 426161 to improve the bug triage process in such a way that a
> bug like this one can't be moderated down early in the development process and
> then have it sleep until it is too late.
> 

I guess that's a start, but this bug has been around (in one form or another) for over 3 years (see bug 267807) so there have been plenty of development cycles to fix it under.

> I don't think any blocking would be required.

You must make sure that the first thread asking for the password blocks until one has been entered and all the others block until the dialog has been closed. But if that is JavaScript, the solution is probably simple: Check if the dialog is already open and wrap the callback instead of replacing it. This way, the answer would be propagated to all waiting threads.

My guess is that there are more issues hidden beneath this which can't be explained in a few hours (and much less in a bug-tracker item with 20 lines of text). That's why no one dared to touch this bug for the last three years.
I really hope this bug gets fixed. I have been using the Firefox password manager and master password for a long time. I frequently use the "Open All in Tabs" bookmark feature to open large numbers of sites at once (saves a lot of time). Many of the sites have log in prompts. In Firefox 2 this task worked great. I now encounter this bug every day with Firefox 3 beta 4/5. I can work around this of course but it's these features that makes Firefox so great. Now's a bad time to start breaking them with the other browsers catching up.

On the other hand Firefox 3 looks great. Whether this is fixed or not I'm sticking with version 3! Thanks developers!

Rob
The Secure Login extension kind of fixes this problem by delaying the password input.

But its being a non-default disablable third-party extension still leaves this a security problem.
Personally, if this bug can't be fixed directly I'd _almost_ prefer Firefox preemptively prompt me for my master password at startup (if one is set) rather than having to work around this bug.
(In reply to comment #50)
> Personally, if this bug can't be fixed directly I'd _almost_ prefer Firefox
> preemptively prompt me for my master password at startup (if one is set) rather
> than having to work around this bug.
> 

Just a note: one of the most annoying issues with AllPeers prior version 0.75 was that it raised the master password dialog every time during start up because of the secure server configuration (from profile-after-change) even a user had not yet been registered. I.e. right after the extension installation. People didn't like it because it was too disturbing.

Other issue is when user refuses to enter the password during start up (IMHO usual case) and have to enter it later than we are at the same trouble.
Status: REOPENED → RESOLVED
Closed: 17 years ago → 16 years ago
Resolution: --- → DUPLICATE
Justin, do you also think that this bug is a dupe of bug 356097? I can remember a statement from you that everything is caused by the same basic fault. Does that also apply here?
I'll go find or create a bug for my comment #13. Sometimes Firefox (maybe Thunderbird and Seamonkey too) needs to ask for multiple passwords and the keyboard navigation gets broken...
Why do bugs get marked as duplicate of this one as this one is marked as a duplicate of bug 356097 ?
Partly because I forgot this one was duped, partly because there's a tangle of these bugs with different symptoms due to the same root cause, and partly because I'm rather fond of the number 369963. :-)
I'm also more fond of this number, this bug also has more votes, and they both have completely different summaries. I think summary of this bug is way better too, because it's not a proxy problem, but a problem with (master) passwords not being reused.

I filed bug 434487 which is also related to these bugs, but describes the case where firefox should prompt more than once as descibed in comment #13 and mentioned in #57 :-)
I disagree completely. It is not just a problem of Master passwords being reused.
It is a problem that happens whenever multiple threads are requesting authentication for the same context: master passwords Or proxy authentication.
Being behind a proxy which request authentication and having configured a master password, the situation is aggravated as Firefox will show a dialog prompt for each simultaneously loading internet pages(or frames) and whats worse this happens also for each basic authentication prompts requested by the proxy server !!
The context is the same for all pages requested: 
  - each pages triggering proxy authentication
  - proxy authentications triggering master login-prompt.
None of the prompts are shared or reused.
So a solution or workaround for multiple master login prompts only is not a viable solution as the user would need to validate all filled in proxy authentication dialog boxes the same way !!!!

PS: This bug is REALY,REALY,REALY,REALY, ...  annoying in corporate offices !
    I don't understand why this has not been solved much sooner as this bug has been manifesting itself from the earliest versions of Firefox with support for session restore with multitabs.

NOTE: This bug is manifesting itself also when upgrading addons @ Firefoxes launchtime. This means that during launch-time firefox request authentication
to the proxy and once loaded also ???!!!

Looking at the summaries I'd say this bug (Multiple master password prompts
instead of an existing one being reused) would be a duplicate of bug 348997
(Session restore causes multiple prompts for same password), but instead it's
marked duplicate of bug 356097 (Master password prompted multiple times on
start-up for proxy authentication).
No longer blocks: 348997
No longer blocks: 356097
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: