Closed Bug 177175 Opened 23 years ago Closed 3 years ago

Should not display more than one "Primary Password" prompts.

Categories

(Core :: Security: PSM, defect, P3)

Product:
Core
Component:
Security: PSM
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
110 Branch
Tracking Flags:
Tracking Status
firefox110 --- fixed

People

(Reporter: mozilla-bugs, Assigned: keeler)

References

(Depends on 1 open bug, Blocks 2 open bugs)

Details

(Whiteboard: [partial workaround: comment 103] [psm-roadblock] [possible cause: comment 84][psm-backlog])

Attachments

(9 files, 1 obsolete file)

Patch v2
26.99 KB, patch
mayhemer
: review-
Details | Diff | Splinter Review
screenshot
56.42 KB, image/png
Details
firefox_mp_bug.png
88.47 KB, image/png
Details
screenshot of two password dialogs
8.57 KB, image/png
Details
Video with hard locked firefox on MacOS
9.32 MB, video/mp4
Details
Screenshot_20220602_170338.png
102.80 KB, image/png
Details
Screenshot of multiple password dialogs
351.26 KB, image/png
Details
Bug 177175 - re-implement PKCS#11 protected auth UI with modern components r?jschanck
48 bytes, text/x-phabricator-request
Details | Review
Bug 177175 - cancel subsequent PKCS#11 password prompts if more than one happens concurrently r?jschanck
48 bytes, text/x-phabricator-request
Details | Review
Summary: when a "Master Password" dialog is shown, any operation that wants to prompt for "Master Password" should attach to the existing dialog, not display a new one. This is a spin-off of bug 95397 (see bug 95397 comment #23). Steps to repsoduce (copied from bug 95397 comment #6): 1) Make sure you have "Encrypt sensitive information" enabled. 2) Set up an NNTP account for a server that requires authentication (I am not sure if passwd-protected POP or IMAP will act the same; if you do not have access to passwd-protected NNTP server, you can try to emulate one by using user_pref("mail.server.servernn.always_authenticate", true); ). 3) Make sure that auth information for that server is stored in the wallet. 4) Set biff ("check for new messages every 1 minutes") on that account. 5) Restart Mozilla (logging out of Password Manager will probably work the same, but haven't tried it). 6) Go for lunch. Expected: when you come back, you have at most one "master password" dialogs waiting for you. Actual: you'll have a *lot* of them. It seems that every time Mozilla tries to check for new messages, the server will ask for authentication and Mozilla will prompt for the "master password". Alternative stepts to reproduce: 1) Make sure you have "Encrypt sensitive information" enabled. 2) Make sure you have save login information for at least two different login forms (for example, Bugzilla's one and some other). 3) Tools -> Password Manager -> Logout 4) In two different browser windows, go to the two login forms from step (2). Expected: Single "Master Password" dialog Actual: Each window has it own. While the first scenario could be considered networking's fault (it should have realized that it needed the same password in all the cases) and could be covered by the bug 95397, the second scenario seems to be a password manager issue.
Blocks: 95397
If it's the prompt for the master password, then that's PSM, not password manager.
Assignee: morse → ssaux
Component: Password Manager → Client Library
Product: Browser → PSM
QA Contact: tpreston → junruh
Version: other → 1.01
Cannot reproduce. Under prefs>Privacy>Master passwords, which radio button do you have selected?
Priority: -- → P3
Version: 1.01 → 2.4
> Under prefs>Privacy>Master passwords, which radio button do > you have selected? "The first time it is needed".
The first scenario is a dupe of bug 96896. The second is not reproducible on Win2000, Linux, or Mac OSX 10.2.2. cc tpreston@netscape.com, Password Manager QA, for comments. *** This bug has been marked as a duplicate of 96896 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Verified duplicate.
Status: RESOLVED → VERIFIED
> The second is not reproducible ... I've just reproduced the second scenario using bugzilla.mozilla.org login form in one window and bugzilla.redhat.com one in another. BuildID 2002112018 (trunk) compiled and running on Red Hat Linux 8.0
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
Sending to Password Manager
Assignee: ssaux → morse
Status: REOPENED → NEW
Component: Client Library → Password Manager
Product: PSM → Browser
QA Contact: junruh → tpreston
Version: 2.4 → Trunk
Reassigning to new module owner
Assignee: morse → dveditz
I can confirm the second part under Win2k. I have a webmail login as my start page for mail. The username/pass are stored in the wallet. When I start mail for the first time (master pass set to check first time needed) I will sometimes get 2 master password prompts depending on the load time for the web browser (one for IMAP and one for the webmail login form). The first appears to be the webmail form the second is the IMAP info. If I enter my master password in the first dialog and cancel the second things still work properly. I'm using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
I observe another bug that may or may not be related: when I want to cancel entering of the Master Password, I have to do it twice in a row. It occurs on http://ej.ru/forum/index.php (need to have a stored password to there).
Product: Browser → Seamonkey
Assignee: dveditz → nobody
I found some interesting info related to this bug. I had a problem of SeaMonkey asking for the Master Password 8 times every start-up. I could enter the MP once and cancel the other dialogs (in the right order, because a newer dialog blocks the old, so you have to cancel the newest first), instead of entering it the 8 times. I though it was related to a profile corruption, because it happened just to one of my profiles, but I was wrong. Today I migrated from a own Inbox for each account (each one of them getting new mail at Mails start-up) to a Global Inbox for every account, except the IMAP one. Now it prompts for the password just twice. It looks like SeaMonkey makes all of the requests before one of them ask for the MP, then each of the requests maintains the state that the MP wasn't entered and each one of them asks for the MP, even if a lot of them already asked for. Putting the accounts in the Global Inbox made SeaMonkey make the requests in sequence, it just starts downloading from one account after the other have finished. It's a good idea to make multiple requests, if we can, off course. So it is not a good solution to make every password request synchrony, but should be verified if the MP was requested at the time of making a new MP request, instead of the server (page) password request.
I see this in seamonkey 1.1.1 if I set the master password to last for only 5 minutes. When it checks mail, it needs the master password. Each such check seems to display a new master password request. I came in this morning and there were 72 of them!!! The correct action is to block on the first request until the user answers it. As a result, it is only feasible to set Mozilla to ask for the Master Password the first time it is needed. This makes things a lot less secure IMHO.
This is problem for me when I have two plugins that (upon firefox startup) tries to login to services (like, for example, Gmail notifier and gmail reader notifier). I have to retype master password twice before finally firefox shows main window. Additionally, what is perhaps more irritating, when first prompt for master password shows and I start typing in, then second one shows and I finish my password in second dialog box. This results in a mess. So I'm +1 for fixing this issue.
Summary: Should not display more than one "Master Password" promts. → Should not display more than one "Master Password" prompts.
bug 369963 is a Core bug - is there any reason to believe this bug isn't a duplicate of it (that is, specific to SeaMonkey?)
(In reply to comment #14) > bug 369963 is a Core bug - is there any reason to believe this bug isn't a > duplicate of it (that is, specific to SeaMonkey?) > This bug ended up with "Product: SeaMonkey" as a result of a ping-pong between various product values back in 2002...
It seems impossible to select multiple products when you enter a bug.
Depends on: 369963
Assignee: nobody → kengert
Component: Password Manager → Security: UI
OS: Linux → All
Priority: P3 → P2
Product: Mozilla Application Suite → Core
QA Contact: tpreston → ui
Hardware: PC → All
mtschrep: can you flag this wanted:1.9 as was the case for bug 369963?
Flags: wanted1.9.0.x?
Status: NEW → RESOLVED
Closed: 23 years ago → 17 years ago
No longer depends on: 369963
Flags: wanted1.9.0.x?
Resolution: --- → DUPLICATE
this was forward-duped for no apparent gain (and then that bug was duped)
Status: RESOLVED → REOPENED
Flags: wanted1.9.1?
Resolution: DUPLICATE → ---
Depends on: 348997
(In reply to comment #20) > this was forward-duped for no apparent gain (and then that bug was duped) That was done because bug 369963 contains more information.
No longer depends on: 348997
early marked this as bug 369963
There should not be any master password dialog at all. Just a sliding bar at the top of the page like with the new remember password behaviour. See bug 461455
Could the prompt for Master Password not happen before Firefox is fully launched. There is a mechanism for looking for updates during FF launch. It might then obviate the need to modify other dependent code????
(In reply to comment #25) > Could the prompt for Master Password not happen before Firefox is fully > launched. There is a mechanism for looking for updates during FF launch. It > might then obviate the need to modify other dependent code???? With FIPS enabled, FX3 needs the master password for checking for updates anyway, because it needs the master password before accessing a secure https website.
(In reply to comment #25) If the user has set an expiry timeout for his master password, even asking it before Firefox starts is not enough. Having said that, I've implemented this functionality as an extension: https://addons.mozilla.org/en-US/firefox/addon/9808 .
You are correct about the timeout. I had a very short timeout and had to disable the timeout otherwise FF was totally unusable. Just tried to apply the extension however it fails to install. "invalid hash file" Thanks
(In reply to comment #28) > Just tried to apply the extension however it fails to install. "invalid hash > file" Strange. I've tried installing it using several different configurations (computer, os, firefox version and language) and found no problem. Are you able to install other (experimental) extensions from AMO? Does anyone else have the same problem? You could also have a look here: http://kb.mozillazine.org/Unable_to_install_themes_or_extensions_-_Firefox#Invalid_file_hash
I made several attempts at logging in to clarify but got distracted. I can't install downloading and installing straight into FF. I get the "invalid hash error". I can install it if I download using IE and doing a file open. Tried with two different Windows machines. Same problem. I will try a couple of others. Could be the combination of addons?? The invalid hash link in your post looks to apply to FF 2 not 3 but what do I know. FF Linux I have no trouble. All that said the extension seems to work well although I haven't tried enabling timeout. I also tried several times to comment on the addons website and got distracted. I seem to have problems concentrating ;) I'll let you know how my testing goes on other machines. Thanks !!!
(In reply to comment #30) > I made several attempts at logging in to clarify but got distracted. I can't > install downloading and installing straight into FF. I get the "invalid hash > error". See bug 437174. Disabling third-party cookies prevents your AMO session details being provided by the XPI installer, so the download doesn't contain XPI data as expected. Add a cookie exception to allow for addons.mozilla.org to workaround.
Done and that was the issue.
This addon seems to totally take care of the multiple master password prompt at FF startup. Other issues may arise when a master password expires (using the expire master password addon) and logged in pages expire and also regularly refresh. At any rate great work.
I have been using this now for a while. I don't suppose that my usage is typical. I have literally hundreds of stored passwords. I use FF portable and my sessions travel with me. My browsing sessions may span weeks. I seldom ever open a fresh session. My current session is very light having just closed perhaps a dozen tabs. I am left with 12 tabs, half of which are logged in, including this one. Most of them expire in 20 minutes to half an hour. I use the master password timeout addon with a timeout of 5 minutes so I get frequent prompts. I may carry my portable drive to different computer several times a day. I mention all this to support that this addon seems to absolutely fix the problem. I get a single prompt prior to FF launch instead of, if this session were restarted, 6 prompts, none of which would actually work. This an old bug. Hubai Tamas seems to have corrected it. Unless there are some things that it causes problems for IMHO it should be considered as a built in fix. Thanks Hubai
I tried the addon it works for the master password. No more prompts for the extensions. But I still got multiple "proxy auth" prompts later when all the session tabs openend. Note that my proxy has the extensions URL configured without proxy password but several of the tabs needed proxy password. Still the addon helps get rid of about 30 dialogs which is quite a progress.
Have you tried the AutoAuth addon for the proxy dialogs? https://addons.mozilla.org/en-US/firefox/addon/4949
I just added AotuAuth to the 3.1 beta 2 on OS X. Now I get an uncaptioned password box when I start Firefox. I presume that is for my master password. Or, it could be a piece of malware trying o steal my credentials......
Voted on this. I not only have to enter the prompt for every password-protected tab I had open when I last closed the session (most of them - intranet stuff while at work), but also for the proxy server. IMO, this is not the sort of bug that should be resolved by installing an extension. Given the age of this bug, I'm a bit concerned that it's been left "UNRESOLVED DONTCARE"
Clearly this is a usability bug. It is a security risk in that if a person gets conditioned to entering his master password into a lot of dialog boxes a malicious app could throw up a similar dialog. I agree with Mike that this is core functionality that cannot be trusted to a plugin. I applaud Hubai for writing the plugin, but I don't know anything about him and am not about to risk my master password.
This bug is a duplicate of bug 348997. This one was started earlier, but the other one has more info and more visibility: Currently 193 comments, 109 users CC'ed, and 74 votes.
(In reply to comment #40) Not really a dupe per se, bug 348997 is a regression, this bug is not AFAICT. The bug there is about session restore where as this one is not. The patch there will probably fix this, adding dependency.
Depends on: 348997
I was not suggesting that the plugin be the fix but that the prompting for the master password prior to FF launching seems to solve the multiple master password prompts.
I originally asked the question as to whether launching the master password prompt prior to FF starting could be a place to start a fix. While Hubai's plugin has made FF usable for me, Brian does have a point that it shouldn't be left to a plugin. I would like to ask if this might be a rather large security hole that it is even possible to launch the master password prompt or tie in to the FF security at all. I use Sxipper, the master password timeout as well as the Hubai plugins. I guess I could be in trouble couldn't I.
This does look like bug 356097
Status: REOPENED → RESOLVED
Closed: 17 years ago → 16 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
No longer depends on: 348997
(In reply to comment #39) > Clearly this is a usability bug. It is a security risk in that if a person > gets conditioned to entering his master password into a lot of dialog boxes a > malicious app could throw up a similar dialog. > > I agree with Mike that this is core functionality that cannot be trusted to a > plugin. > I applaud Hubai for writing the plugin, but I don't know anything about him and > am not about to risk my master password. Totally agree with you. And this bug still reproduce in FF 3.6b5. I do not understand how it is posibble it is still not resolved after so many years. This bug scares away many users ....
This is not a dup of bug 356097. Bug 356097 is for *proxy* authentication only and was only fixed for that particular scenario. Unfortunately, there are many other reasons why one could get multiple master password prompts (password forms in multiple tabs, etc) and those are not yet fixed.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
Depends on: 499233
Depends on: 356097
This is particularly painful when restoring a session that had multiple tabs logged in. The solution is not "restore one tab, enter master password, restore rest of tabs" , nor is it "do not restore session". And as others have said, a plugin is not where this should be fixed.
(In reply to comment #48) Actually, my mistake, there is bug 348997 specifically related to restoring sessions. Not that that's fixed, either. I doubt solving one wouldn't solve the other.
I believe I made the first comment about the plugin actually fixing the problem. I agree that the problem should not "fixed" with a plugin but if the plugin does solve the problem why hasn't whatever the plugin did been rolled into the core. The issue goes back to FF 2 so this is a very old issue with serious security implications not just usability, as have been mentioned many many times.
I haven't tried the plugin, nor have I looked into how it actually works. I'd assume it prompts for password on startup, then blocks? Or does it only prompt on the first attempt at using a password-ed tab? If it does the former, it's not quite the same as 'fixing' the issue, though it's masking it sufficiently well. I don't particularly understand why there isn't an option to require the master password to even use the browser (which I also think that plugin provides, based on skimming its page and the comments on it). But, again, that would only mask the problem, even if it was done within FF. They're clearly different issues, though. Multiple concurrent prompts for the master password can't possibly be sensible in anything but the smallest of occurrences (if at all).
In the end it doesn't matter. Multiple prompts for a master password are a serious security issue that has NOT been addressed in the core application for an unbelievably long time. If it isn't something that can be solved then IMHO that feature should be removed.
I am using FF with the master password plugin in an production environment. Without this it's completely unusable! People in my office have started to switch to MSIE. So if the developers don't care about enterprise deployement, they may care about loosing popularity? The plugin does not solve all mass-popup problems. Some times there is the plugin new-version-check. This goes before the master-password plugin. Result is, because of password protected proxy, a massive amount of empty (!!! why?) popups with a password field. As many as there are plugins installed. A horrible mess. Solution? killall firefox. On next restart the checker does not run. Ok, one could also simply disable automatic plugin checking.
Assignee: kaie → nobody
Whiteboard: [psm-roadblock]
Please try the following as a workaround (which is still ugly): - enter the master password into the topmost prompt - for each of the remaining prompts, it may be sufficient to simply press enter (without entering the password) This works for me, if I get more than one prompt at startup of thunderbird.
yeah, that workaround has been stated a couple times before, works for me too. I recently found another nice extension that solves this mostly, bartab. https://addons.mozilla.org/nl/firefox/addon/67651/
It is partly because of annoyances like this, and the fact that after 8 years it is still going on, that I have switched to Google Chrome and have no intention of switching back. I still do use Firefox occasionally on computers that I don't have administrative rights to and so would still like to see this fixed for myself. Honestly this reflects poorly on the Mozilla team / community that a security and usability bug like this has been around for eight years despite fixes to at least parts of it having been made by add-on developers. At the very least roll some of the add-ons' code into the core.
Attached patch Patch v1 (obsolete) — — Splinter Review
Does this patch work? Please test and give feedback, thanks.
Assignee: nobody → kaie
BTW, the patch is against mozilla-1.9.2, Firefox 3.6, Thunderbird 3.1 I've tested with TB 3.1, my profile usually gives me multiple prompts because of email and calendars, seems to work for me with this patch.
Patch also seems to work in FF 3.6, according to my tests. /me crosses fingers nobody reports regressions. So, even if this patch works, it's not yet complete, but the remaining work should be straightforward. (This patch disables the smartcard related protected-authentication-path functionality)
(In reply to comment #57) > Does this patch work? > Please test and give feedback, thanks. Kaie, could you create a tryserver build people can use to test this patch?
(In reply to comment #60) > (In reply to comment #57) > > Does this patch work? > > Please test and give feedback, thanks. > > Kaie, could you create a tryserver build people can use to test this patch? Builds arriving here: http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/kaie@kuix.de-26223793bd5a/ (trunk, mozilla-central, so beware, very experimental code!)
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/kaie@kuix.de-26223793bd5a/ Please be aware, that directory is short lived, the test builds go away within 2 weeks. If you can help to this for regressions, please do. We'd be grateful for any feedback. The more you test, the quicker this can be solved. Thanks.
Yes, it seems to work. When I start Firefox with multiple pages remembered that need a password, I only get a single prompt. I don't even get additional prompts if I click cancel. There is a minor glitch, however. After I enter the master password, only one of the tabs will have its password field pre-filled. For the other tabs, I have to manually refresh the page. Having said that, it's much better than the previous situation. Thank you, Kaie. (Tested on Linux 2.6.31)
Tamas, thanks a lot for your testing. When I tested, all open tabs received the pre-filled passwords, I wonder why that doesn't work for you.
I'm curious too. Tried again with yet another profile, but the results are the same. Anything else I should test?
(In reply to comment #64) > Tamas, thanks a lot for your testing. When I tested, all open tabs received the > pre-filled passwords, I wonder why that doesn't work for you. You're not per chance running some auto fill add-on like SecureLogin?
Julz, if you're asking me, I performed all my experiments starting from a clean profile, without installing any add-ons. I used the following steps: 1. Unpack the .tar.bz2 version of Kaie's tryserver build. 2. Run './firefox -no-remote -ProfileManager' from the new firefox/ directory. 3. Create a new profile called, say, test7 (incrementing the counter each time). 4. Exit, and run './firefox -no-remote -P test7'. (do not change default browser, and don't check it every time). 5. Set a master password in Edit -> Preferences -> Security. 6. Open three different pages on separate tabs with a password field on each. For better reproducibility, I used the following three temporary subdomains: http://pwtest1.ces.hu/ http://pwtest2.ces.hu/ http://pwtest3.ces.hu/ (Side note: it seems that I can even use the same page 3 times.) 7. For each tab, fill in the password field, submit the form and ask Firefox to remember the password. 8. Close Firefox, keeping the tabs open, and restart it with the same command. 9. Fill in the master password dialog, and observe the results.
So, what's with this bug? Why it hasn't been in trunk yet? A patch is provided, so where's the problem? I've got another situation when multiple master password requests appear. If you switch between normal and anonymous mode, the tabs restored in normal mode request the master password again. I think even forgetting master password when switching to anonymous mode isn't the desired behavior, but one can go over it. But I ask you if the provided patch works also for this issue. StartupMaster extension doesn't solve this issue. I don't know how to test the patch with my current FF 3.6.13 or TB 3.1.7.
This bug has like 3-4 dups, most annoying and even causes deadlocks when a large number of master passwords are spawned, at least here on linux. It really needs to be fixed, someone please review the patch.
I just found bug #499233 that they seem to have fixed in in firefox 4.
First, I failed to ask someone for review. I somehow forgot that. Second, the situation may have been improved, because of bug 499233. Question: Is anyone of you using Firefox 4 beta, and still experiencing this bug? Please give feedback. If yes, it's time to get this patch reviewed.
Also waiting for feedback in bug 536140
Attached patch Patch v2 — — Splinter Review
patch merged forward
Attachment #454051 - Attachment is obsolete: true
I have done some testing, with Firefox 4 beta and multiple notifier addons. Firefox never gave me multiple prompts. I tested Thunderbird 3.3 alpha, with Lightning Calendar nightly, using a caldav calendar, and a google calendar. Thunderbird 3.3 is based on mozilla 2.0b, same as FF 4 beta. On Startup, Thunderbird gave me three (3) master password prompts. I conclude the core issue is still not fixed. In Firefox, it simply may have a sufficient workaround. We should get this patch into Mozilla, so a future of Thunderbird can benefit from it.
Attachment #514027 - Flags: review?(honzab.moz)
I built Thunderbird 3.3 experimental, with this patch added, and I only get one single password prompt.
Have a following scenario: - apply the patch - have a site requiring a client cert - have a page that redirects e.g. with <meta> to that site in say 15 seconds - have a client cert for the site + its CA imported (I'm using the same CA for the test site and the client cert) - set a master password - set select client cert automatically - open the page that will later redirect to client auth requiring page (you can do it more then ones, for more fun) - open options/security/saved passwords, do not enter the master password yet - wait for the page to redirect, that invokes soft-token login via a different code path, you will still see just one dialog - after the page apparently tried to redirect, submit the master password Expected: saved passwords are shown Actual: saved passwords are NOT shown, same behavior as if the dialog were canceled If I just want to see the saved passwords (no background load in progress) I can see them after submitting the master password. Without the patch the passwords are shown, but I have to submit the master password in both dialogs. This may be a simple bug related to the saved passwords window revealed by this patch or something more general showing problem with the patch. I can see one problem and that is thread concurrency. If we (as described above) call PK11_Authenticate on a slot from two different threads then we on both call C_Login on the same slot twice, very short after each other. According to PKCS11 2.20 spec: "C_Login may be called repeatedly, without intervening C_Logout calls, if (and only if) a key with the CKA_ALWAYS_AUTHENTICATE attribute set to CK_TRUE exists, and the user needs to do cryptographic operation on this key. See further Section 10.9." I don't know NSS well enough to say if we are protected also against another potential issue, relogin while we are processing a non-atomic operation on the slot: "If there are any active cryptographic or object finding operations in an application’s session, and then C_Login is successfully executed by that application, it may or may not be the case that those operations are still active. Therefore, before logging in, any active operations should be finished." Also, you are not looping the even queue on other threads then the main thread. Why exactly? I may potentially lead to a deadlock.
Comment on attachment 514027 [details] [diff] [review] Patch v2 r- based on comment 76.
Attachment #514027 - Flags: review?(honzab.moz) → review-
Refering comment 71 I had this problem when starting the browser, and then FF restored all my tabs, going through corporate proxy and so on. The problem was there till FF3.6.16, I did not experience in FF4 (some alpha till 4.01), however the problem is definately there in FF5.0b2, though the number of master passwords dialogues is somewhat less, but this is probably a timing thing. (FF3 x4-6 dialogues, FF4 x1 dialogue, FF5 x2 dialoges for now).
This problems also exists in Thunderbird as it uses the same nsILoginManager.
Blocks: 584014
I have just installed FF 11.0 on Ubuntu and have this same problem. I've had it previously, forget when, then it went away and now its back. Simply put, multiple FIPS master password dialog boxes - seems to have settled down to 2, the second which can be canceled. Few days ago, I somehow had about 4-5 blank boxes piled up at 1 time but that hasn't happened again. This happens when I am going to a secure site - it does not happen when I request show passwords (just 1 box there). I'll try it in safe mode now...
It just reoccured in safemode restart - bugzilla came up then 2 dialog boxes, 1 on top of the 2nd. A prior extra annoyance - a lag in the 2nd box appearance, causing interuption of p/word entry - does not seem to be in effect. I call that a step in the right direction. I only run 1 extension - AdBlock+
I bet this is occurring more frequently now because we can now do multiple SSL handshakes concurrently since bug 674147 was fixed, and I bet each SSL handshake causes a prompt. (In reply to Jeff G. from comment #83) > A prior extra annoyance - a lag in the 2nd box appearance, causing > interuption of p/word entry - does not seem to be in effect. I call that a > step in the right direction. I bet this is related to what I described in the sentence above: instead of doing SSL handshakes one after another, we now start multiple SSL connections immediately. Thus, the second (and later) prompts come up sooner. Maybe we should talk to the UI team to figure out if/when we will have a design that fixes the spoofing problem with the master password dialog box. I can see how a new UI design that fixes that problem could effectively prevent this from happening. (I believe a new UI for the master password is due to arrive eventually for the "Sign into the browser" feature.) AFAICT, doing the master password prompting as part of the SSL handshake, leaving the SSL connection idle, is not great for security (even disregarding the UI spoofing issue), because it interacts badly with our TLS intolerance timeout scheme; I worry that the time we spend waiting for the user to enter the master password is counted towards the TLS intolerance timeout.
This bug has gone on for way too long, and it seems to me affects everyone who cares about security and thus uses a master password. Surely the solution is to ask for the password (if one is set) as soon as Thunderbird starts, and before anything else is done?
(In reply to Brian Smith (:bsmith) from comment #84) > I bet this is occurring more frequently now because we can now do multiple > SSL handshakes concurrently since bug 674147 was fixed, and I bet each SSL > handshake causes a prompt. And that explains how I ended up here. When using a current daily build, I am getting 3+ master password prompts. I could not figure out why, but that lines up with the number of accounts I have, give or take which ones I have check for email on startup (so that many SSL handshakes on startup alone). So does that mean a temporary fix is to disable certain accounts from checking mail on startup, and kill the number of handshakes? As an aside, some people have promoted the use of Startup Master (https://addons.mozilla.org/en-us/thunderbird/addon/startupmaster/), but its performance seems so-so in stable, and terrible in the Daily builds (if it even worked at all).
(In reply to alharaka from comment #86)that > lines up with the number of accounts I have, give or take which ones I have > check for email on startup (so that many SSL handshakes on startup alone). Lightning calendars make password prompts, too. > As an aside, some people have promoted the use of Startup Master > (https://addons.mozilla.org/en-us/thunderbird/addon/startupmaster/), but its > performance seems so-so in stable, and terrible in the Daily builds (if it > even worked at all). I've been using StartupMaster for a long time - happily with the current stable build.
This bug re-appears on Firefox 11. I had seen in much earlier versions (maybe firefox 3 or so) but it has been fixed until update to firefox 11.0. So I downgraded to Version 10 and get only one master password dialog - as expected. Stefan
(In reply to Stefan Schäfer from comment #88) > This bug re-appears on Firefox 11. I had seen in much earlier versions > (maybe firefox 3 or so) but it has been fixed until update to firefox 11.0. > > So I downgraded to Version 10 and get only one master password dialog - as > expected. > > Stefan Stefan, would you be please willing to narrow down which one of Firefox 11 Betas started to produce two MP dialogs? You can find Fx11beta builds here: http://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/ Thanks.
Okay, I will try to check this. And I'll post my findings here. stefan
After testing I found that the bug appears with the very first Version "Firefox Setup 11.0b1.exe" I'm using a Portable Firefox installation. So I installed the Beta to \firefoxportable\app\firefox. I made sure that my profile in the 'data' directory is the same - although I used actually a copy ;-). I crosschecked and installed the "Firefox Setup 10.0esr.exe" the same way. Version 10 works fine, version 11.0b1 contains the bug. I tried to overwrite simply the firefox.exe with the older version - but the bug still persisted. hope that helps stefan
Almost definitely bug 674147 or related to that work, as mentioned in comment 84.
Just for the records: When I disable FIPS but still use the Master password I get only one prompt for the Master Password. Stefan
Whiteboard: [psm-roadblock] → [psm-roadblock] [possible cause: comment 84]
(In reply to Stefan Schäfer from comment #93) > Just for the records: When I disable FIPS but still use the Master password > I get only one prompt for the Master Password. TLDR summary: FIPS mode also has an impact for me, not sure why. Full explanation: What version of Thunderbird are you using? I had mixed results, but I had to refine how I was testing this. On my updated Daily build I tried running it in Safe Mode (with all add-ons disabled). My client profile: Version: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120319 Thunderbird/14.0a1 ID:20120319030043 Extensions: Adblock Plus 2.0.3, Add-on Compatibility Reporter 1.1, Adobe Acrobat 10.1.2.45, Bugmail 1.6.1, Default 14.0a1, Force RTL 2.1, iTunes Application Detector 1.0.1.1, Java Deployment Toolkit 6.0.260.3 6.0.260.3, Java(TM) Platform SE 6 U26 6.0.260.3, Lightning 1.3, MailSentry IronPort Spam Reporter 1.4, Microsoft Office 2010 14.0.4730.1010, Microsoft Office 2010 14.0.4761.1000, Nightly Tester Tools 3.2.1.1, NVIDIA 3D VISION 7.17.12.6696, NVIDIA 3D Vision 7.17.12.6696 ,Provider for Google Calendar 0.9, QuickTime Plug-in 7.7.1 7.7.1.0, Remove Duplicate Messages 0.1.10, Shockwave Flash 11.1.102.63, StartupMaster 1.3 [DISABLED], TBTracer 0.6 [DISABLED] ,Test Pilot for Thunderbird 1.3.7, VLC Multimedia Plug-in 1.1.11.0, WAT 1.3.2, Windows Activation Technologies 7.1.7600.16395, Xythos Drive 4.5.10839.1 My Usage (Profile Config): - 4 IMAP accounts * 2 Gmail/GoogleApps email addresses * 2 standard IMAP accounts to Mirapoint work appliance (IMAP4rev1 compliant with the follow capabilities: ACL QUOTA LITERAL+ NAMESPACE UIDPLUS IDLE UNSELECT) * Lighnting-enabled, with one Google Calendar account * One WAT (Web Applications Toolbar) tab open for Google Reader (credentials secured via master password) Testing Variations: Safe Mode, FIPS Enabled: 3 Prompts Safe Mode, FIPS Disabled: 1 Prompt Regular Mode*, FIPS Disabled: 1 Prompt Regular Mode*, FIPS Ensabled: 2 Prompts * For me, regular operation is a batch or shortcut (%USERPROFILE%\QA\thunderbird-12.0a1.en-US.win32\thunderbird\thunderbird.exe --profile-manager --no-remote; I mention since threading might be an issue here). Needless to say, however, I got a lot of variable results. I flat out disabled Startup Master, which I was convinced was making it worse. Strangely enough, when I re-enabled FIPS mode at one point (before moronically testing without Safe Mode), applying settings to *re-enable* FIPS brought up three prompts. In my testing, I also had numerous cases where I got more than 1, 2, or 3 prompts. I can safely assume some of those are from well-behaving, or even misbehaving plug-ins. But still, FIPS mode seems to have an impact. Not sure why. I also imagine whether or not I have a variety of accounts open, enabled for startup mail pull, or tabs for WAT and/or Lightning open makes a difference, but I have noticed it does consistently go down when I disable FIPS.
(In reply to Martin Pecka from comment #87) > (In reply to alharaka from comment #86)that > > lines up with the number of accounts I have, give or take which ones I have > > check for email on startup (so that many SSL handshakes on startup alone). > > Lightning calendars make password prompts, too. Agreed, but I can get upwards of five or six sometimes, which means more or less equal or exceeding the number of email accounts and a Lightning tab. I know I cannot have total bliss and just one for now, but the number I frequently get gives me a headache, and I am not the average user. > I've been using StartupMaster for a long time - happily with the current > stable build. Yeah, it does appear to work well with stable, but that might not be the case for long if my experience with the Daily build shows anything. It does not work as advertised most of the time with Daily (Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120319 Thunderbird/14.0a1 ID:20120319030043), but I am not sure why yet.
The master password dialog box often appears several times in superposed instances and appears always when we don't need it (grrrrr !). Could it appear only when we need to access to a password and not 30s after Firefox start, justwhen we bigin entering something in Google ? FF 11.0 French under Windows
(In reply to f1jek01 from comment #97) > The master password dialog box often appears several times in superposed > instances and appears always when we don't need it (grrrrr !). Indeed it is very annoing, that the password dialog alwasy steals the focus. It would be nice if firefox would check the actual focus and when an input field is focussed, that does not require a known password, prevents the password manager from popping up. I open firefox with two sites that require a password. But when I type something into the search field the PW-manager always catches the last few letters of my input. Stefan
Build identifier: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Firefox/11.0 SeaMonkey/2.8 With the above version this bug still exists: a possible solution to this bug : Check if the Master Password Prompt is prompting for a password and it is visible and prompting then it should not do not display all the remaining Master Password Prompts. IF there is no visible Master Password Prompts then it should be display one prompt Do this only in one thread ( maybe a dedicated thread for Master Password Prompt ) - so there is no duplicate displays of Master Password Prompt
In version 12.0 the bug stil persists.
(In reply to Stefan Schäfer from comment #100) > In version 12.0 the bug stil persists. is that Thunderbird?
Nope, Firefox 12.0.
A new feature "Sign into the browser" is coming soon and I am pretty sure that it will change lots of things regarding how the master password mechanism works, and that work will probably lead to a new UX for master password which will likely fix this bug. But, such work on "Sign into the browser" will not start for several weeks or more; I don't even know what changes to Master Password and related stuff will be neded for it yet. Workaround #1: I recommend that everybody that has FIPS mode enabled disable it. There is really not a significant security benefit to the FIPS mode; it is more for government regulatory compliance. Also, Firefox does not automatically become FIPS compliant when you enable the FIPS mode; there is a series of additional, undocumented (even I do not know all of them) steps that must be completed. Workaround #2: Disable the master password and rely on operating-system-level account management/passwords/encryption. I understand that this won't work for everybody, and for the people it does work for (AFAICT, most people) it requires learning how to effectively use the operating-system-level features, but IMO it is by far the best solution, even after we fix this bug.
Whiteboard: [psm-roadblock] [possible cause: comment 84] → [partial workaround: comment 103] [psm-roadblock] [possible cause: comment 84]
This still exists in Seamonkey 2.9.1 (Build identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120429 Firefox/12.0 SeaMonkey/2.9.1) This is exhibited when FIPS mode is enabled, after an update. The addon check will prompt for the master password for each and every addon update check.
Fixing this bug would just make things easy for everyone even disabling the FIPS mode, a workabout as suggested above in the thread does not guarantee that there will be only one prompt. Build identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120429 Firefox/12.0 SeaMonkey/2.9.1)
From what I can tell I MUST have FIPS on. I have a security hardware device (USB). I'm running Windows XP. Telling me to try and understand how Microsoft deals with the security hardware devices is like asking a programmer to cast a spell using the Egyptian Book of the Dead. It's not going to happen and asking someone to do it is just plain insulting.
Just in passing, I thought FIPS was required when using a master password but I'm no expert on this.
(In reply to Jeff G. from comment #107) > Just in passing, I thought FIPS was required when using a master password > but I'm no expert on this. It's the other way around... A master password is required to use FIPS. FIPS is not required to use a master password.
Ok, I had it backasswards - thanks.
Bonjour, For several months, and today with Firefox 14.0.1, each times I start Firefox it ask me the master password at least 4 times (this is very disagreeable !). How to solve this bug ? The home page of my Firefox is zimbra.free.fr webmail to access my mail account. I use a lot of extensions ... My PC OS is Windows XP. Pierre
Hi Pierre. Unfortunately, this problem is not completely resolved yet. We are still trying to track down a regression range so we can identify the code change which caused this bug. If you could, can you please try some previous Firefox releases to see if this bug was introduced in a particular release? You can find our past releases here: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/
reassign bug owner. mass-update-kaie-20120918
Assignee: kaie → nobody
is bug 349641 related to this one?
Hello, I've got Aurora 18.0a2 (2012-11-14) and since some a few versions, Firefox askes me multiple times Master Password depending to (well I think so) how many saved tabs I've got which need passwords. So if you have 3 tabs and you need password on each tab, you'll get 3 master password popups. It should be asked just one time. Thank you. ;) Regards, _kud
The root cause of these problems (as in comment 110) is that the password is filled in automatically. A regime more like Opera, where the password is filled in only upon user request, would resolve all these problems with multiple master password dialogs. This problem in the past has also occured for me with session restore, where a dozen different tabs might want the master password to fill in some info. I've even seen it lead to deadlock situations where it becomes impossible to actually type the password into one of a dozen pw dialogs. I have not looked for a bug requesting an option for only-on-user-request filling of info that requires a master password, but that option would imho be very useful.
That wouldn't be a solution, as this bug affects not only filling forms. It affects also websites that use certificate based authentication, thunderbird email accounts and much more. I'm wondering why it's not possible to implement a simple semaphore around opening the security device. I could imagine the following behaviour: 1. Check whether the security device is already open. If so exit. 2. Use a blocking lock on something when opening the security device is requested, but the device is still not open. 3. After the thread got the lock, check again whether the security device has been opened during waiting for the lock. Act as in 1. after unlockung the something from 2. 4. If the device has not been opened yet, go on and display the password dialog and try to open the security device as usual. 5. On success or cancellation of the opening process unlock the something from 2. independent from the result. What's the problem with that idea, except that it might hide other bugs which are possibly widespread around the code. But even such code can be examined much better: In case a thread does not get the lock immediately the locking function could generate a stacktrace both of the thread that holds the lock and the thread that tries to interfere.
Is there any improvement on solving this bug? It's VERY annoying that you get a 2nd password dialogue, and you don't even notice it, because both are placed in the same position with the same size... only if you started typing the password you could guess, that a 2nd dialogue has opened, because the characters you typed suddenly seem to have disappeared. Interestingly, I only have this problem in the office, running Windows XP, and not at home running Windows 7. I already created a completely new profile on my office PC, but it didn't solve the problem. Is it so difficult to resolve? For me it seems as if there is no progress since 10 months, but in the meantime, 3 new major releases have been released...
For me, there is no improvement, I have this on my 2 computers (7-32 and 7-64). If you open FF and even if you do not browse any web site, the master password will appear after some timeout, this is normal. If, just before this moment, you start browsing a web site needing a password (thus the master password), the 2 ones will appear superimposed : the "time-out" dialog and the "password needed" one. This in only my feeling...
No improvement here too. Quite boring. I've got like 5 pined tabs which all require password, I've got 5 popups displayed.
if any of the folks that can easily reproduce this has the cycles to follow anthony's suggestion in comment 111 to find a regression range, it would be much appreciated :)
I am using Secure Login with Firefox Beta, and recently my Secure Login bookmark for Wikipedia started showing two Master Password prompts instead of one.
Just looking at these comments, this seems to go back 11 years!
Its nearly impossible for a normal user to try to find a regression range. As James said: it is far too late to talk about a regression, here. Maybe it is more useful to ask for stack traces (and provide easy step by step instructions how to obtain them).
(In reply to Aleksej [:Aleksej] from comment #122) > I am using Secure Login with Firefox Beta, and recently my Secure Login https://www.mozdev.org/bugs/show_bug.cgi?id=25628
The same problem occurs when using the add-on "Pocket", which stores its password in the wallet.
This is still happening in FF 27.0.1
(In reply to Chris Brousseau from comment #128) > This is still happening in FF 27.0.1 Expect this to continue to happen until a patch with a fix is landed.
Just curious: What are the chances that a TWELVE year old bug is going to get fixed? Having very _little_ experience coding, is there anything I could do to contribute to a fix?
Confirmed: this is a most annoying bug.
Thunderbird 24.4.0 - still happening. Using Lightning. Switching from "Provider to Google Calendar" to using caldav actually helped for a while. But when I added another Google calendar using caldav I started getting multiple prompts again. And there are another addons, that require access to master password, but additional Google Calendar seemed to push it over the edge again.
As has been said several times before - there's a (very well working) workaround to this - the Startup Master addon ( https://addons.mozilla.org/en-US/thunderbird/addon/startupmaster/ ). So no need to switch to CalDAV or any other workaround solutions...
(In reply to Roberto Bagnara from comment #131) > Confirmed: this is a most annoying bug. (In reply to Virgo Pärna from comment #132) > Thunderbird 24.4.0 - still happening. > Using Lightning. > Switching from "Provider to Google Calendar" to using caldav actually helped > for a while. But when I added another Google calendar using caldav I started > getting multiple prompts again. And there are another addons, that require > access to master password, but additional Google Calendar seemed to push it > over the edge again. Guys, STOP commenting on this bug. See comment #129.
I don't know if it's fixed but I don't have this problem anymore on 31.0a1 (2014-03-19).
The problem is still not fixed, but may not happen to everyone. If you set security.use_mozillapkix_verification to false (about:config), the problem still shows up, so a second master password dialogue is shown (and placed exactly above the first). If set to true (default), it does NOT happen - at least not to me. Since the default for this setting is true, which seems to be the case starting with ff 31.0, not all users might see a second dialogue... maybe this helps in finding/debugging the problem.
interesting hint, dirk, but i still see multiple (3? 4?) master password dialogs every time firefox starts up and restores my ridiculously busy session. my security.use_mozillapkix_verification is set to default (true).
I saw someone speculating somewhere whether this issue appears in Firefox 31.x.x or not, and I can sadly report that it does still exist in Firefox 31.0.0 and has been with me since 22.0.0 (if I remember correctly). I'm on Ubuntu 12.04 LTS, and this must be one of the most annoying bugs in my system. Just wanted to let you know.. ;) Installing the StartupMaster-plugin to see if it helps.. hoping that this will be fixed soon, cause Firefox/Mozilla has been my preferred web-frontend since years, and it's just awesome.. Keep up the good work Mozilla et.el, and cheers for all, for now!
I must admit I have a hard time understanding how this bug is not solved after 12 years and given there is at least one add-on (startupmaster) which solves the problem by just asking the password before anything else.
@Renaud, i feel your frustration, but those of us who aren't offering patches have no right to complain :P FYI: i have StartupMaster version 1.6 installed and enabled and i still see multiple password prompts whenever firefox restarts and loads my insanely huge session via Session Manager :-/
Problem is reproducible for me with FF 34.0.5 on Win7.
Flags: wanted1.9.1?
(In reply to Marc Bejarano from comment #141) > ...but those of us who aren't offering patches have no right to complain I hope you realize that not all bug reports are from developers. Most are from general users reaching out for help from the TB developer community. Oh, I have a patch for you - uninstall Thunderbird and replace it with something else.
Reproducible for me too with FF 34.0.5 on Win7 64Bit.
Win8.1 64 bit, FF 36.0.4 (but it was the case with the previous versions too): Gmail is my starting page in Firefox. When I start FF right after I started Windows, it opens Gmail and prompts me for the master password in 2 (or sometimes 3) different windows. Even though I enter the correct password in all of the windows, the Gmail user/password fields remain empty. When I close Firefox and then restart it, everything works well.
Multiple password prompts still happen to me with Thunderbird 31.5.0 on Ubuntu 14.10 64bit
Firefox 38.0 beta on Win7Sp1 64bit it happen to me as well my very first time I experience this =?
Should probably be renamed to "The Everlasting Bug"…
why not just incorporate startup master into everything and be done with this!
Maybe for the mozilla folks, it's more important to throw a new version every 2 weeks on the marketplace than to care about the really annoying bugs... by the way: did every watcher here VOTE for this bug? I see 115 addresses on the CC list, but only 88 votes... but at least, this won't help anyway...
Still have it with 37.0.2.
(In reply to ermolaev from comment #151) > Still have it with 37.0.2. Please refrain from posting unsolicited "still broken" comments in bug reports. Doing so just adds noise to the bug and doesn't actually help in reaching a solution. If you want to help, we need someone to find a regression window (comment 111). Otherwise, you should have zero expectation this is resolved until the bug report has been marked RESOLVED.
Please refrain from posting "Please refrain from posting unsolicited 'still broken' comments" comments. Doing so just adds noise to the bug and doesn't actually help in reaching a solution. If you want to "educate" the offending reporter, send him private email.
(In reply to peter blicher from comment #153) > If you want to "educate" the offending reporter, send him private email. I am not singling out the commenter but the comment itself. Since multiple people are coming to this bug making the same mistake, public education is warranted. Please email me directly if you want to discuss this further but do not engage in this behaviour on Bugzilla. Thank you.
I had never suffered from this bug until the recent update of TB (38.0.1) to include Oauth2 security. Now every time I start TB it asks for the mater password 5 times. Before I switched my Gmail account server settings to use Oauth2, even after the upgrade to 38.0.1, it only needed the master password entered once. Then I changed the authorisation method to Oauth2, went through the pop-up browser verification exchange, and all seemed well. However, at next start-up of TB I got the 5 master password requests.
Imagine I use master password. I saved a password on a certain website. Now I restart my firefox. I use a private window, I go to this website, it asks me the master password, I cancel, I do an error when I want to log in, it asks me again my master master. Quite boring. When you click on cancel, it shouldn't ask you again your master password. It could have these buttons: "Yes", "No", "Forget me for this session". Plus why master password is used for private sessions?
Report/comment in two parts - Mozilla/System data, and then a statement of impact. First, Mozilla Thunderbird and System Details (let me know if more data is required): Thunderbird 38.0.1 OS X 10.10.4 Model Name: MacBook Pro Processor Name: Intel Core i7 Processor Speed: 2.6 GHz Number of Processors: 1 Total Number of Cores: 4 L2 Cache (per Core): 256 KB L3 Cache: 6 MB Memory: 16 GB Next, Statement of Impact: Just adding my seventeen cents... I cannot believe that this issue has cropped back up and could be thought of as low priority or even FAD. IMHO and educated opinion, this bug has been in the wild for a public release for too long. I have cleared all saved passwords; tried OAuth2 vs. "Normal password" for accounts that support it; turned the master password on and off; several combinations of those steps tried; re-created the security DB (being ambiguous on purpose); and, I reviewed Thunderbird configuration and nothing stands out. I do not even know what I could pull back from backup for application support or even application file replacement tests, and I am not about to spend time figuring it out or go nuclear and just replace ~/Library/Thunderbird. I have four email accounts: three IMAP and one POP3. With the master password enabled, I have to enter the same master password four times. Every time I launch TB. This is incredibly irritating, it is super strange that this bug got through QA since Mozilla is one of the few well-known vendors that use this approach to security and do not simply rely on the OS X Keychain, and with a new GA version of Firefox just getting rolled out, it would be nice if someone got what worked just fine pre-38.0.1 to work again in a one-off that could include a fix just for the master password issue. It would be a very nice thing to do for your users that choose to use your software because of what is a higher level of securing access to data we choose to save. As what I hope to be a very temporary workaround, the master password is turned off. Someone that knows: please share some information regarding ETR or anything to help us know what's what with this super annoying bug. Thank you.
(In reply to Bryan from comment #158) > ... > I have four email accounts: three IMAP and one POP3. With the master > password enabled, I have to enter the same master password four times. Every > time I launch TB. > ... Although this is an irritating bug, I'd like to add (again) that it is not necessary to type the master password repeatedly. You can Cancel the extra prompts or OK them, if the password is empty. The first entered master password remains active that way.
I read that and I am aware of that. But how many TB users are reading this thread? This bug is not even assigned. I am doing my part to add some emphasis that this problem should be solved sooner rather than later for sake of the entire user community. I am also not going to have some sheet appear more times than it should. I refuse to accept that multiple prompts is FAD and not worthy of assignment for a fix, and also go along with the idea that multiple entries for those who are unaware can be resolved with a "Cancel" button click is FAD for the current version of the software. If one entry is all that is required and the other n-number of sheets are redundant and do nothing, then why not fix the problem by showing the master password sheet only once, just like the versions before 38.0.1? I am the only user of my computer with FileVault enabled (OS X FDE) and solid security for the rest of my computer, so I am not too worried about disabling the master password to get rid of the irritation and the need to do anything to get rid of something that is a bug *for now*, but I am a resourceful user that happens to be aware of this thread for a still *unassigned* bug, and not all TB users out there today know about this thread and probably think Mozilla put out a junk update and have let it sit for a while too long (autoupdate or no). I trust that someone who can fix this in the Mozilla dev world can do what needs to be done when Mozilla gets around to noticing it and considering the bug's impact on the typical user, and that a proper update will be released eventually. The only reason I provided the impact statement and have followed up with this complaint is that this is something that can be fixed, but each time I look at this bug, it remains unassigned. That's all, and I am done posting comments on this. Do what you will. Messages for this thread are going straight to my still-working junk folder now. I'll take an update with a fix for this when there is one.
> Although this is an irritating bug, I'd like to add (again) that it is not > necessary to type the master password repeatedly. You can Cancel the extra > prompts or OK them, if the password is empty. The first entered master > password remains active that way. And how should I tell whether the n'th incarnation of the master password dialogue appears due to this bug or because of a typo in the first shot?
Have you tried the 'Startup Master' Addon? That has solved it for me. I agree it would be nice to get its code integrated into the core for both FF and TB... BUT... Please refrain from unhelpful comments - your rant and subsequent 'threat' (for lack of a better word) to send all emails about his bug to Junk was ridiculous, unnecessary, and I don't see how you could even remotely think it might actually help motivate someone to fix this. You do realize that ALL Thunderbird devs are 100% voluntary now, right?
This is still a bug in Firefox thats Mozilla support. Using Master Password App does not solve the issue. Yes Cancel works, but the issue is that you have to spot that you have two windows open prompting for passwords. I expect Mozilla to fix this in time for the end of the year, unfortunately based upon past experience it will be by 2050
(In reply to cpohle from comment #161) > > Although this is an irritating bug, I'd like to add (again) that it is not > > necessary to type the master password repeatedly. You can Cancel the extra > > prompts or OK them, if the password is empty. The first entered master > > password remains active that way. > > And how should I tell whether the n'th incarnation of the master password > dialogue appears due to this bug or because of a typo in the first shot? Looking at my Linux Computers: The behaviour looks like an unsolved race condition. All Password requests are open at the same time, each from a different thread. So it should be sufficient make a critical section out of that code that ensures the existence of a valid master password. Using the usual locking mechanism you could aquire a mutex *before* the program checks whether a valid master password exists. This mutex must not be released before a valid master password has been entered or the process has been cancelled. If the process is cancelled all waiting threads can be saved in a special table just before releasing the mutex. After getting the mutex a thread might check for beeing in that table. If so, it and removes itself from the list and returns in the same way as if the cancel button had been pressed without showing the master password again. If there are different functions that check for the master password and/or show the dialog, All must use the same mutex. In the long term this behaviour must be avoided. E.g. there should be a master function and all copies call this function. This is the standard solution for parallel processing. What is so difficult that this cannot be implemented by someone that • knows the architecture of the mozilla library, and • knows the used programming languages? If the mozilla team is not able to maintain this piece of code. They should disable the master password feature at all, because that also implies that they cannot ensure that the master password does not leak from this part of code!
(In reply to Nigel from comment #163) > This is still a bug in Firefox thats Mozilla support. Using Master Password > App does not solve the issue. Which one did you try? There are more than one... I'm talking about 'Startup Master': https://addons.mozilla.org/en-us/firefox/addon/startupmaster/
So, you dismiss my recommendation to use the 'StartupMaster' Addon because some other Master Password Addon you tried didn't work? Brilliant.
(In reply to Charles from comment #167) > So, you dismiss my recommendation to use the 'StartupMaster' Addon because > some other Master Password Addon you tried didn't work? > > Brilliant. @Charles - the reason I dont use StartupMaster Addon is because it does not do the same thing if you had taken the time to check. The addon I use times out after a period of inactivity, whereas the one you are suggesting does not. As using a password is for security reasons, its safer to have the master password lock after a period of inactivity.
I would have never even considered such a 'feature' as anything but something to disable if I encountered it. Imnsho you are doing this in the wrong place. Timing/locking out a session is what you should be using your screensaver/lockout for. This protects your entire workstation, not just one app. I would be extremely annoyed by what you are wanting and would either disable such a feature or uninstall the Addon if it didn't provide for a way to disable it. But whatever floats your boat.
I tried disabling all addons and email account, but didn't work for me. Then I solved removing some unused 'chat accounts'. Now I finally got only one master password request with 3 imap accounts enabled.
Another way to reproduce it (in Thunderbird): 1. Configure an IMAP account which tries to update after starting TB 2. Restart TB. You will see the master password prompt 3. Don't enter anything, just wait ~5 minutes until the server times out and closes the not-yet-authorized session 4. TB tries to reconnect (probably in a new thread) to the server which again asks for the password. Another master password prompt appears where the old one is still there. Conclusion: No plugins are involved in this bug, they only cause the problem to appear more often.
An unresolved, reopened bug, dating back to 2002? I would not wish to be contentious, but... come on... I stumbled on this just now after setting a master pwd on my TB. It is a shame that the only viable mail client left around is so neglected by MF. I am not a programmer... but... is it possible to move the code part that checks/asks for master password before the thread spawning? No need to delay that check until threads detect that the credentials in signons.sqlite are encrypted, I guess...
For the record, StartupMaster works for me too: https://addons.mozilla.org/it/thunderbird/addon/startupmaster/ thanks to the nice guy that written it. I have no idea why this bug is still here after 12 years, given the existence of a patch and an extension solving it. It seems to me to perceive the same haughtiness leading to TB still working with mailbox format instead of maildir++ in 2015. Cheers.
(In reply to Poohs from comment #155) > I had never suffered from this bug until the recent update of TB (38.0.1) to > include Oauth2 security. > > Now every time I start TB it asks for the mater password 5 times. > > Before I switched my Gmail account server settings to use Oauth2, even after > the upgrade to 38.0.1, it only needed the master password entered once. > Then I changed the authorisation method to Oauth2, went through the pop-up > browser verification exchange, and all seemed well. However, at next > start-up of TB I got the 5 master password requests. I am in the same situation. Details: Windows 8.1 x64 Pro Everything worked fine until my latest upgrade to TB 38.2.0 and enabling Oauth2 on my gmail account. It's more than annoying.
Correction: It did not start with using Oauth2 but after subscribing to my Google Calendar. There were three dialog boxes opened. Once I removed the subscription there is only one Master password dialog anymore.
I'm seeing 5 prompts. Thunderbird 38.2.0. I looks like its 1 for every calendar in Lighting.
(In reply to BArry from comment #176) > I'm seeing 5 prompts. Thunderbird 38.2.0. > > I looks like its 1 for every calendar in Lighting. Possible. But I only had configured one Google Calendar and the default "Home" calendar. => 2 prompts Plus one for all mail accounts.
See Also: → 1199607
How can this not be fixed now. From a google search, this bug goes back to 2009. https://www.google.com/search?q=firefox+asks+for+master+password+twice&ie=utf-8&oe=utf-8 Duplicate bug or not ....
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 "Provider for Google Calendar" causes this issue in my case. Disabling it solves the problem. Note: I do not use gmail (so no Oauth2) or any exchange calendar add-ons, which seem to also cuase this issue (as reported in the comments above). I use https://addons.mozilla.org/en-US/thunderbird/addon/startupmaster/ as a work around.
I agree with Tobias (comment 164). This appears to be a classic race condition that should be easily fixed. It is amazing that it has existed so long with out being fixed. I first saw this after the TB 38.2.0 update when I decided to use Lightning to manage my Google calendar using the "Provider for Google Calendar" add-on. This was the first time for me that TB got a second request for the security device during start-up. I am currently using the StartupMaster add-on as a work-around, but this is far from ideal. When TB is started with this add-on, the add-on requests the master password with the usual prompt before the TB window appears. Thus, the prompt hangs out there without a cue as to what it's for. Yes, I know the context from the fact I just requested TB to start, but if I'd started several programs it would be less clear. I also understand this is probably the only place that StartupMaster can be effective. I just wish this add-on was not needed, and TB contained the proper fix.
Tim, NONE of the TB or Firefox password prompts give their context. You know it is a Mozilla product because they are the only prompts that ask for a password for the security device. And very few of us use a security device.
(In reply to James Rome from comment #181) > Tim, > > NONE of the TB or Firefox password prompts give their context. You know it > is a Mozilla product because they are the only prompts that ask for a > password for the security device. And very few of us use a security device. ...And, that is why it is a bug. Because: 1. You might have multiple profiles and multiple Mozilla products, all with different passwords. 2. The prompt could be spoofed. Probably the prompt should offer not only what product and profile it refers to, but even its own "password" to prove it's genuine.
It is a bug, but s nothing to do with this one. File a separate bug.
(In reply to James Rome from comment #181) > Tim, > > NONE of the TB or Firefox password prompts give their context. You know it > is a Mozilla product because they are the only prompts that ask for a > password for the security device. And very few of us use a security device. I concur with Peter's comment #182. The issue I have here is that the work-around to do what a bug fix should do, is left has to invoke the TB password prompt without any context that it is working for TB. See also comment 39. But, the add-on work-around issue only drives home the real issue, and that is this bug must be fixed. That it has not been fixed after 13 years is astonishing.
(In reply to James Rome from comment #183) > It is a bug, but s nothing to do with this one. File a separate bug. Experience shows that filing such bug reports rarely leads to useful changes, but often requires a lot of work in answering comments denying it should be fixed or offering workarounds. For example, see bug 177175. Experience also shows that comments such as the one I made directly above usually lead to comments that the best way to get a bug fixed is to fix it yourself. Therefore, I will also say that I would gladly do that, if only the code were adequately documented so that it did not require years of study to understand.
(In reply to peter blicher from comment #185) > Experience also shows that comments such as the one I made directly above > usually lead to comments that the best way to get a bug fixed is to fix it > yourself. That how it is with free software sometimes, especially when there is very little paid developer resources available. Why is that so hard to accept? Why do you insist on constantly bashing Thunderbird, when the bottom line is there are basically ZERO paid developers working on it? Frankly, I'm VERY pleased with the progress it is making since Mozilla cut our legs out from under us, and have nothing but praise for those kind souls still willing to work on it while people like you spit in their faces.
(In reply to Charles from comment #186) > (In reply to peter blicher from comment #185) > > Experience also shows that comments such as the one I made directly above > > usually lead to comments that the best way to get a bug fixed is to fix it > > yourself. > > That how it is with free software sometimes, especially when there is very > little paid developer resources available. > > Why is that so hard to accept? Why do you insist on constantly bashing > Thunderbird, when the bottom line is there are basically ZERO paid > developers working on it? Frankly, I'm VERY pleased with the progress it is > making since Mozilla cut our legs out from under us, and have nothing but > praise for those kind souls still willing to work on it while people like > you spit in their faces. I am not bashing thunderbird, and I am not "constantly" bashing thunderbird. I am just explaining why I do not intend to file a separate bug relative to the comment I made earlier, and why it is not practical for me to fix it myself. As a matter of fact, I do accept it, though I don't like it. At this point, I would say the future existence of thunderbird itself is in question, unfortunately. So, I am happy that it even still exists.
(In reply to Charles from comment #186) > (In reply to peter blicher from comment #185) > > people like > you spit in their faces. BTW, insulting people is not likely to endear either you or the project to them; on the contrary, it turns people off and damages the project.
I'm wondering about the priorities regarding bug fixing and implementing new features. A bug like this one, years old, doesn't get fixed, instead a lot of new features get implemented. Some of those features are really important, but a lot are only "nice to have", and I don't get it, that fixing existing bugs have a lower priority than implementing new features... yes I know, there are volunteer developers who don't get paid working on firefox, but there are also some, who do get paid, and who should have the knowledge about managing projects. So it's time to re-think priorities here, and fix a bug, that is annoying thousands of users! And I don't mean this as bashing the people here, but maybe it's time to check the processes...
(In reply to peter from comment #187) > I am not bashing thunderbird, and I am not "constantly" bashing thunderbird. > I am just explaining why I do not intend to file a separate bug relative to > the comment I made earlier, and why it is not practical for me to fix it > myself. All of which was just a nice/polite way to bash it. Sorry, but I just get tired of these kinds of comments. If you can't contribute positively, just don't say anything. > At this point, I would say the future existence of thunderbird itself is in question, > unfortunately. So, I am happy that it even still exists. Then you haven't been keeping up - Thunderbird development has actually improved dramatically since Mozilla canceled all active developer resources (although they do still maintain the infrastructure, which is still significant, so thanks to them for that).
(In reply to peter from comment #188) > BTW, insulting people is not likely to endear either you or the project to > them; on the contrary, it turns people off and damages the project. Precisely why I responded to your comment like I did. Maybe it didn't deserve quite such a harsh reply, so apologies for that, but it absolutely was being insulting, regardless of how nicely you phrased it. So, maybe you should reconsider how you phrase comments like this...
(In reply to Dirk Wissmann from comment #189) > I'm wondering about the priorities regarding bug fixing and implementing new > features. A bug like this one, years old, doesn't get fixed, instead a lot > of new features get implemented. Some of those features are really > important, but a lot are only "nice to have", and I don't get it, that > fixing existing bugs have a lower priority than implementing new features... > yes I know, there are volunteer developers who don't get paid working on > firefox, but there are also some, who do get paid, and who should have the > knowledge about managing projects. > > So it's time to re-think priorities here, and fix a bug, that is annoying > thousands of users! And I don't mean this as bashing the people here, but > maybe it's time to check the processes... The problem you seem to not understand is, it isn't a process problem. The process works just fine, once you understand that there are currently no (or very little) PAID developer resources working on Thunderbird. This means that the volunteer contributors work on what they want to work on, and I am grateful to them for what does get done. If, on the other hand, there were paid developers, then it would make sense to suggest implementing a process for assigning the bugs that no one wants to work on to those paid developers.
Dear Developers, (In reply to Charles from comment #190) > All of which was just a nice/polite way to bash it. > > Sorry, but I just get tired of these kinds of comments. If you can't > contribute positively, just don't say anything. It would be very, very, very nice, if would be as sensitive for help offers (see e.g. Comments 124 and 130) as you are for bashing. Once I tried to track down the spot in the source code where the error resides, but stepping through houndreds of JavaScript calls and other levels of scripts makes it impossible to track the problem down using gdb if you don't know what you are looking for. It would be really helpful if you could provide a link that explains how to get a proper backtrace from the Script code. On the other hand, you should also honour that every single comment in this bug report has been made by an unpaid freelancer in your QA team. Probably those people spent much more time in exploring the bug, finding the bug database, using a search engine to find the particular ticket, and expressing their will to help than it would take to fix the bug. And please, those who want to want stop users from sharing their experience should set a good example and stop commenting in this thread, too. Of course, unless they are willing to contribute to the debugging process.
I just finished reviewing the comments for this bug. I'd like to commend the developers who have contributed much of their time and apparently delivered some solutions over the long period this bug has existed. That there is still an issue seems to be due perhaps to regressions or other circumstances. That said, I'm wondering whether any of the developers are currently looking at the code to attempt to fix this. I'd guess not since the bug is currently unassigned, but I grant that some investigation may still be on-going. It's just not visible to us vis-a-vis the comments here. As has been suggested in several comments, this appears to be a classic race condition that could be solved by making the object that handles fetching the master password, when one is needed, a singleton object. There are design patterns widely available which describe how to implement this. The tools needed to do that are also widely available, such as pthread_mutex_lock, pthread_mutex_trylock, or even pthread_mutex_timedlock depending on the desired effect. I'm sure the Mozilla/Thunderbird are well aware of these. The question boils down to how important this bug is to the developers. It has usability and security implications, so I would think it should be higher than it apparently is. That there is at least one add-on that can be considered a work-around may be why the priority is not higher. However, the add-on I have in mind, StartupMaster, does not provide the context necessary for the general user to know the prompt is in connection to a Mozilla product. Because of this, it is possible for maleware to spoof the password prompt. So, this work-around is certainly less desirable than a Mozilla product solution. I think we'd all agree it would be nice if we had some assurance from development they are actively working toward a solution.
For anyone who decide to work on this bug: Version 10 works fine, version 11.0b1 contains the bug. So it should be possible to find a solution by comparing these two Versions.
Sorry I missed: I refer to Firefox (not Thunderbird) if there are any doubts.
For those who are as frustrated as I am at the challenges reflected in the comments above regarding paid and unpaid resources, then perhaps, between over 100 of us, we might raise the bounty that relates to this issue to a high enough level to reward someone willing to apply their time and knowledge toward this bug. Perhaps we could all pledge a handful of notes/coins at https://www.bountysource.com/issues/3490877-multiple-entry-of-master-password-required. For anyone who is involved in the Mozilla administrative side of things, of which I know nothing, perhaps there may be a way to work more actively to facilitate Bounty Source as a financing model. I say this because I love open source, and often find there are significant papercuts not getting attention. I'd really rather not leave the desktop email space to Apple and Microsoft.
Confirmed bug in ThunderBird 38.3, under Linux Ubuntu 14.04.3. Exactly as described in comment 13 https://bugzilla.mozilla.org/show_bug.cgi?id=177175#c13
Confirm problem with environment described in comment 198. Thunderbird 38.3.0 and Linux Ubuntu 14.04 LTE with last update.
(In reply to Stefan Schäfer from comment #195) > Version 10 works fine, version 11.0b1 contains the bug. So it should be > possible to find a solution by comparing these two Versions. hi stefan. it's refreshing to see actual useful information in a sea of noise :) it sounds like you have a repeatable test case and a desire to contribute. perhaps you're up for doing a bisect regression search to figure out which nightly started causing the problem for your particular test case? https://mozilla.github.io/mozregression/
Flags: needinfo?(stepfahn)
See Also: → 1232151
Keywords: regressionwindow-wanted
tb 38.5.1 on Mac OS X El Capitan. I have 4 accounts and 5 open tabs restored on startup. I am asked 4 times for my master password. This seems to have more to do with the number of accounts than the number of tabs. Also, I noticed that when the main window opens, a pop-up comes up asking for the master password, then immediately disappears, then is replaced by another master password prompt (and then 3 more -- presumably once for each account). I wonder why that first prompt shows and is then automatically dismissed.
Confirmed still present in Tbird 38.5.1 running on Win 7 x64 All this time I thought it was me fumblefingering a long and complex pw. Only start Tbird about once every 10-14 days but when I travel it's really annoying. 13+ years now? Wow.
Not sure whether it is useful, but it is still badly broken in 38.5.1 on Ubuntu and Win10. Guys, I have 5 mail accounts, and I don't need to explain how much pain is it to type a *master* (!) password 5 times every time I open my mail client, especially when the password prompt windows pop up on top of each other before I finish typing. Such a pain. I turned the calendar off long time ago, I never needed it and never really asked for it to be on by default, and I never dreamed that it'll have such an annoying annoying side effect. It really defies the meaning of a "master password". Pleas, please fix it.
I probably should have explained that the problem surfaced when a release came out with the calendar (was it Lightning?) turned on by default, don't remember the release number now, devels would know better. So bad was the effect that even turning off everything related to Lightning and removing all Google Calendar accounts did not help. I somehow assumed that everybody knows that it is triggered by the inclusion of Lightning.
It isn't Lightning, it is anything that prompts for passwords - so, in this case, it was your Google Calendar accounts. If you were using Lightning with only local calendar(s), it wouldn't be a problem. Anyway, since the Startup Master Addon solves the problem, that is the solution for now unless/until someone decides to fix this. Since all Thunderbird development is now voluntary, complaining/whining (not aimed at you, but if you had bothered to read the comments in this bug you would know all of this) is not the best way to call attention to issues.
Startup Master is not a solution but a workaround, and yes, I am aware of it. And while Lightning itself might not be a problem, I have reasons to believe that inclusion of it into 38.0.1 (checked now) somehow triggered the bug - not my Google Calendar account. I had 5 mail (IMAP) accounts and 3 XMPP accounts, and a large number of SMTP accounts, all asking for passwords, all with different security settings, and everything worked like charm on any operating system until the Lightning stroke. I do some voluntary software development myself, and I know that bugs can be left to rot for years, but I also know that a good number of reminders might help prioritising them.
Well, there have certainly been a large number of comments and reminders over the many years this bug has been open. Aside from the inconvenience of multiple prompts, which has increased with adding Lightening as a default addon, this bug is a security issue. I'll point out again that StartupMaster, does not provide the context necessary for the general user to know the prompt is in connection to a Mozilla product. Because of this, it is possible for maleware to appear as the password prompt. So, this work-around is certainly less desirable than a Mozilla product solution. As I understand it, this bug is common to Firefox as well as TB. This should raise the interest and priority for providing a native solution. I fully realize that TB support is very limited. I'm thankful for all the developers do. There is a need to balance fixing bugs and working on new features. New features are always more fun. Bug fixes ensure you keep users happy with the product and it's working properly. We have no visibility of how many important bugs are being worked on. We should assume there are many. Because this one involves product security, we hope it's one that's considered important.
(In reply to Tim Johnson from comment #209) Exactly, this is not just an annoyance but an evidence of a logical lapse in a security-related component. Hiding this by a workaround might actually exacerbate the problem and lead to serious breaches, especially if somebody develops a tool to fetch the master password from StartupMaster. Since Firefox and Thunderbird both rely on NSS, the problem might even be over there, and for some odd reason it was trigggered (again) in Thunderbird 38.0.1, perhaps because Lightning was one drop too many in that broken logic. But these are just my not-too-educated guesses. I wish the devels could take it as seriously as a security problem can be taken.
Someone said: If you debug a program don't ask what is written in the source code. Be as stupid as possible and ask: “What does the computer actually do.“ So I doubt that the often repeated request to bisect the source will be very helpful. Some technical detail. I once tried to figure out, where the error lies. I'm not familiar with firefox or thunderbird development, In particular I'm not familiar with XUL debugging. But I know how to debug C/C++ programs. As the threads hang until at least one proper password has been entered I guess it would be possible to gain valuable information by wolking through the call tree at the moment when all password windows are open but no password has been entered yet. So I attached gdb to my thunderbird process at that point and ran “thread apply all backtrace full”. This lead to a huge amount of function calls. Only few of them are generated by machine code. Most of them are some calls to some script subroutines. Going through all the corresponding data structures and finding out which function is called by some function call is a huge pain. At least going this way. If someone can link a webpage that shows how to get a simple call stack/tree for all threads that tells function names and line numbers of the source files at the given point this would enable us to find the error. After trying to decrypt the backtrace I did some search on Ohloh.net. It seems that the password API is implemented twice. Once as compiled source (C/C++) and once is some scripting language (XUL?). Neither of the two seems to reference the other. When I take into account that there are so many script calls to analyse, I guess the script password API is simply broken and should be rewritten to use the compiled one for two reasons: hardware language is more basic that script interpreters and the problem is more prominent when extensions are added (which probably have more access to script APIs than to C/C++ APIs). That is the point where I cannot help out further: • I don't know, how to get readable information about the really interesting information of the call stack, my request to give some hints has been gracefully ignored by all experts, • I'm completely unfamiliar with XUL and both the scripting language and the interface to compiled code • I'm completely unfamiliar with the design goals of the software and I don't have the resouces to figure it out in long discussions • I don't have the resources to do long compiling sessions, namely bisecting the sources. My feeling is that it is useless to bisect as this issue had been considered to be solved by some people, when it never disapeared at my computers. So no one can tell, whether the result of bisecting does really point out the source of the problem or whether this is just one border case that works on a limited number of systems büt will not change anything for the broad masses.
Tobias, if you're brave enough to walk the dark paths of stack frames, the process is not that painful. On Windows, just use Visual Studio. Go to Tools->Options->Debugging->Symbols, add http://symbols.mozilla.org to the symbol server list. Then attach debugger to a running TB, wait until symbols are loaded, and then pause TB in the debugger. All the threads with their stackframes (with named functions and locals) are available to you. On Linux, I'd try something similar with gdb.
If you entered your password in one dialog and another appears, you can simply cancel it (esc key or button). I belive thunderbird then interrupts the current activity, but most processes try it several times and the second time is successful because the password store is already unlocked at that time. (In reply to Oxana Smirnova from comment #205) > Guys, I have 5 mail accounts, and I don't need to explain how much pain is > it to type a *master* (!) password 5 times every time I open my mail client, > ...
To Daniel's comment, this is a work-around of sorts that at least doesn't involve a third party addon solution. It's been mentioned before, so is known to some of us. But, while it doesn't have the security exposure that StartupMaster has, it does require insider knowledge that the multiple password prompts really only require one correct entry, and the rest can be dismissed. As a workaround, that expects a lot from the user. I applaud Tobias for his great attempt to follow the call stack and get a handle on what the code is up to. Having worked with a number of multithreaded programs myself, and doing so with a good understanding of the source code to start with, this can be daunting. I know sometimes developers are so used to the way their programs work, that it takes some adjustment to think like a novice user trying to learn the program, perhaps to decide if it is one the user wants to continue with or look for another. Getting multiple password prompts for no apparent reason is likely to cause one to think the program is not very well done. We know that's not the case, but users generally don't, especially new ones. TB developers: Who's your audience?
(In reply to Oxana Smirnova from comment #210) > I wish the devels > could take it as seriously as a security problem can be taken. Quoting https://mail.mozilla.org/pipermail/tb-planning/2015-December/004318.html : "It seems to me the current answer to "what can be done" is to hope that we can attract more volunteer developers, or try to get more or better work out of those who are currently active. [...] I don't think that answer is realistic, but it is no fun to ignore users with problems, either. [...] The Thunderbird code base is too large for a handful of volunteers to feel responsible for the many critical issues that are only affecting a small minority of users. [...] I do not want to be made responsible for everyone's critical issues, merely because I decided to volunteer some time to the project. For many open source projects, the users are primarily developers, and at least in theory those developers have the ability to fix bugs that annoy them. But as a project directed to end users, we do not have that advantage."
(In reply to M Lopez-Ibanez from comment #215) Interesting reading, now I feel profoundly guilty for bothering fine people who meant no harm. But one of them actually introduced the bug, and not many years ago, but very recently. People who volunteer their time and contribute their code must realize that they will have to fix the bugs they introduce, too - not expect others to volunteer to fix them.
(In reply to Oxana Smirnova from comment #216) > But one of them actually introduced the bug, and not many years ago, but > very recently. People who volunteer their time and contribute their code > must realize that they will have to fix the bugs they introduce, too - not > expect others to volunteer to fix them. If you can point out which commit introduced the bug, the author, if he/she is still around and didn't give up, may feel some motivation to fix it. Finding this is often not easy. I suggest you try to appreciate the difficulty of it.
(In reply to M Lopez-Ibanez from comment #217) > > If you can point out which commit introduced the bug, the author, if he/she > is still around and didn't give up, may feel some motivation to fix it. > Finding this is often not easy. I suggest you try to appreciate the > difficulty of it. If you can point me to the nightly builds or better yet, revision builds, I can do some regression testing. And a note aside: if I was your grandfather or a single mother with 3 kids and 2 jobs, would you suggested the same? Or you'd recommended to switch to Outlook?
(In reply to Oxana Smirnova from comment #218) > (In reply to M Lopez-Ibanez from comment #217) > > > > If you can point out which commit introduced the bug, the author, if he/she > > is still around and didn't give up, may feel some motivation to fix it. > > Finding this is often not easy. I suggest you try to appreciate the > > difficulty of it. > > If you can point me to the nightly builds or better yet, revision builds, I > can do some regression testing. No idea, sorry. Perhaps this? http://mozilla.github.io/mozregression/documentation/usage.html This would be the place where I would start: https://wiki.mozilla.org/Thunderbird/Development > And a note aside: if I was your grandfather or a single mother with 3 kids > and 2 jobs, would you suggested the same? Or you'd recommended to switch to > Outlook? I doubt either of them will have time or know or care about reporting such a bug. I'd recommend them to install the addon, if not, then live with it, if not, then use Gmail. (I'm not a thunderbird dev, but I have volunteered for free software projects with way more users than devs, and I understand how overwhelmed and dispirited they must feel).
In terms of e-mail clients, TB has pretty low market share (1%) as reported by https://emailclientmarketshare.com/. But then, the share has been rapidly moving toward mobile e-mail. I'm not sure how that relates to raw number of users for TB. It still seems like it should be a pretty large number of users, however. Certainly there are a lot more users than developers. I'm sure those developers are proud of their work, and the service their product is providing to millions of users. I hope that at least one or two of those developers see the value in fixing this bug. Since this bug affects Firefox as well, I hope one or two of FF developers see that value as well.
@Martin Pecka: As I already mentioned: I did use gdb. And I installed the debug symbols. But they are useless for script languages. At the moment I don't find the backtrace log that I generated at that time. In princible the problem is similar to the following: The debug stack consists to more than 90% of calls to “call_script_function(call_structure)” where the call_structure consists of houndreds of lines and the information äbout the called script function is hidden 3 layers and 100 lines below. So it's very time consuming to find out what which function has been called with which arguments. In order to do proper in vivo debugging there should exist debug tools for the script languages like XUL that are much better suited for the current problem than a binary debugger.
(In reply to Tim Johnson from comment #220) > In terms of e-mail clients, TB has pretty low market share (1%) as reported > by https://emailclientmarketshare.com/. But then, the share has been rapidly > moving toward mobile e-mail. I'm not sure how that relates to raw number of > users for TB. It still seems like it should be a pretty large number of It is the only FOSS e-mail client in that list, though. Raw numbers: https://blog.mozilla.org/thunderbird/2015/12/thunderbird-active-daily-inquiries-surpass-10-million/
This is also a bug with Firefox that Mozilla still have not resolved! The Firefox team should really resolve this bug as its a security related issue, instead of sitting back and ignoring it and hoping to port a fix from the TB codebase
(In reply to Nigel from comment #223) > This is also a bug with Firefox that Mozilla still have not resolved! > > The Firefox team should really resolve this bug as its a security related > issue, instead of sitting back and ignoring it and hoping to port a fix from > the TB codebase I use up-to-date Firefox on the same platform where my tb has this issue. I see no problems with ff, but I do not use the Password Manager with ff.
(In reply to Christopher Schultz from comment #224) > I use up-to-date Firefox on the same platform where my tb has this issue. I > see no problems with ff, but I do not use the Password Manager with ff. What information do you want to give us? If you don't use password manager there is no "master passwort prompt" at all? Thanks, great Info!!!!1!
Flags: needinfo?(stepfahn)
(In reply to Stefan Schäfer from comment #225) > (In reply to Christopher Schultz from comment #224) > > I use up-to-date Firefox on the same platform where my tb has this issue. I > > see no problems with ff, but I do not use the Password Manager with ff. > > What information do you want to give us? > If you don't use password manager there is no "master passwort prompt" at > all? > > Thanks, great Info!!!!1! I was trying to say that I don't encounter this problem on Firefox, but I don't use the Password Manager at all (in ff). I keep multiple tabs open to a site which has e.g. HTTP Basic authentication enabled and, when restarting ff, I only see a single prompt for the site, not one prompt for each tab that is open. The tb behavior seems to be to ask for the Master Password one time for each account that will be opened.
For the record, I have a master password and have Firefox Sync enabled. I normally am prompted for the master password twice, however if I manage to get it quickly in, I can only be asked for it once.
(In reply to Nigel from comment #227) > For the record, I have a master password and have Firefox Sync enabled. I > normally am prompted for the master password twice, however if I manage to > get it quickly in, I can only be asked for it once. Exactly the same issue.
After I had disabled FIPS for several years and for more than a year don't use masterpasswort at all, because my Linux-System is full encrypted, I tested the issue today and enabled FIPS and masterpassword in both Firefox and Thunderbird on Linux. In neither of them I see more than one master-password prompt. Now I will have to test the situation on Windows System, and I'll report later.
(In reply to Stefan Schäfer from comment #229) > After I had disabled FIPS for several years and for more than a year don't > use masterpasswort at all, because my Linux-System is full encrypted, I > tested the issue today and enabled FIPS and masterpassword in both Firefox > and Thunderbird on Linux. In neither of them I see more than one > master-password prompt. Now I will have to test the situation on Windows > System, and I'll report later. You have to have a gmail account in thunderbird to see this issue. Or a google calendar connected.
(In reply to Stefan Schäfer from comment #229) > After I had disabled FIPS for several years and for more than a year don't > use masterpasswort at all, because my Linux-System is full encrypted, I > tested the issue today and enabled FIPS and masterpassword in both Firefox > and Thunderbird on Linux. In neither of them I see more than one > master-password prompt. Now I will have to test the situation on Windows > System, and I'll report later. You have to have a gmail account in Thunderbird to see this issue. Or a google calendar connected.
Same issue for me. Mozilla Firefox asks for Master Password once but Mozilla Thunderbird asks me for it three times. I am using Ubuntu Linux 14.04 with kernel 3.13.0-76-generic #120-Ubuntu SMP. Fully updated.
With the version 38 series of Thunderbird I encountered a this repeated request for the Master Password issue under Windows 7. In my case I got the password entry dialog twice. A little playing around indicated that one request was satisfied to access two imap accounts hosted by GoDaddy and the second request was to access a gmail account (only these accounts are defined). I completely removed all files from Thunderbird profile directories under my Library(primarily by deleting C:\Users\<user>\Library\AppData\Roaming\Thunderbird but also the Thunderbird directory under AppData\Local. I was able to work around the issue when I eventually found this posting to an apparently abandoned technical forum: http://reviewstash.com/viewtopic.php?id=1872 I found that key to making the double request was to clear in just one of the accounts (the 3rd added account: the gmail account) the "Check for new messages at startup". This solved the problem for me for Thunderbird 38.5.1 under a fully patched as 31 Jan 2016 Windows 7 system. Feel free to contact me if any of this is unclear.
I can confirm the results of Comments 179 & 180: Name Thunderbird Version 45.0 User Agent Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 Application Build ID 20160407161913 Lightning 4.7 true {e2fda1a4-762b-4020-b5ad-a41df1933103} With Lightning enabled I get 8 password prompts -- if I disable Lightning I get one prompt. So I tested further and enabled Lightning again, but disabled Provider for Google Calendar 2.7 (a62ef8ec-5fdc-40c2-873c-223b8a6925cc} - I now only get 1 Master Password prompt. I use the same addon in SeaMonkey (Windows and Linux) and do not experience the same. My problem appears to be: https://bugzilla.mozilla.org/show_bug.cgi?id=833272
I found out an easy solution for me. Maybe it helps others, or even helps finding the reason: I am using Firefox and Thunderbird both with master passwords on Windows 2003 server. In Firefox I never had the issue with multiple master password prompts (300 open tabs). In Thunderbird it started with some update maybe 1-2 years ago: on every start 3 prompts. When entering the password in the topmost one, the second one gets visible and gets focus, so I can immediately enter it a second time. Then the 3rd one gets visible but doesn't have focus, so I have to click it first. I tried many things like disabling checking for emails on startup for some of my > 3 imap acounts, but it all didn't help. Always exactly 3 prompts. Disabling Lightning or the gmail account also didn't help. FIPS was never enabled. Now after reading this thread, I can verify that just clicking OK on prompt 2 and 3 is enough - much easier! But then I tried an idea. I had 2 chat accounts, one for gtalk, one for facebook. I just tried out that feature when it was introduced and then disabled both accounts and forgot about them. *** Now I deleted those inactive chat accounts from the TB account manager and the annoying issue is gone! *** It really annoyed me a lot. Good bye.
Ha, that works! Thank you! I had disabled chat accounts as well, which I would have kept (prepared) otherwise. But removing them I only get one master password prompt instead of two.
See Also: → 720672
I have no chat accounts, and I still get multiple master password prompts with the latest version. I do have 11 calendars in Lightning sync'ed to Google Calendar, and I get 11 master password prompts.
My situation: I use Firefox Sync, and when starting up Firefox, I open two tabs, each of them showing a login page, in which username and password will be filled automatically, as soon as I enter the master password. A few seconds after the first password prompt, the second one opens, so I have to click "cancel" there in order to complete my password in the first prompt. That's it. Nothing more. And this bug is still annoying, now for almost 14 years according to the first comment...
Component: Security: UI → Security: PSM
Priority: P2 → P3
Whiteboard: [partial workaround: comment 103] [psm-roadblock] [possible cause: comment 84] → [partial workaround: comment 103] [psm-roadblock] [possible cause: comment 84][psm-backlog]
Confirmed with Thunderbird: 38.8.0 with Lightning: 4.0.5.2 and Exchange EWS Provider: 3.7.0 on Linux: Ubuntu 14.04.4 LTS With Lightning and EWS plugins enabled I get 3 prompts for the master password. After disabling Lightning I get 1 as expected.
Confirmed for Icedove 45.2.0 (with Iceowl and LaTeX It!)
I am using Thunderbird: 45.3.0 with 10 email accounts configured, which gave me 6 Master Password requests on startup (appears to be for Microsoft accounts only). On searching for information on the problem, I found this post in the Mozilla Support Forum: https://support.mozilla.org/en-US/questions/1132064#answer-921877 I chose to use the StartupMaster Addon workaround: https://addons.mozilla.org/en-GB/thunderbird/addon/startupmaster/ This works extremely well, asking for the Master Password as part of the startup process. I found reference to this bug and find it hard to believe that the problem was first reported in 2002 (now 14 years ago!). Why cannot Thunderbird be updated to offer the functionality of the Addon in the core code when a user wishes to use a Master Password???????
(In reply to Nigel from comment #227) > For the record, I have a master password and have Firefox Sync enabled. I > normally am prompted for the master password twice, however if I manage to > get it quickly in, I can only be asked for it once. Me too. Very annoying.
Unbelievable !! This bug goes back to the year 2002 and nobody has worked on it yet. Thunderbird in the newest version 45.4.0 , we are nearly in 2017, still asks the master password for every IMAP account. I want to enter a "Master" Password only once. And it is terrible that people rely on add-ons to fix the problem. I, as a normal pc user, will trust Mozilla. But I do NOT trust add-ons that handle my passwords. I am a normal pc user and i have no means to find out what the add-ons really do. People that use this workaround are always at risk. This could potentially become a greater security risk and easy way to fish passwords when more people write add-ons.
Bug confirmed with Thunderbird: 45.4 with Lightning: 4.7.4 with Enigmail: 1.9.5 on Windows 7 64bit By the WAY, same result if i disable the extentions and restart the program.
So, the problem lies in logins.json in user's profile and in the way it is parsed. If for some reason block IDs "id" are not in a straight order and have gaps (like, "id":2 is followed by "id":4 or such), Thunderbird believes they have no relation to each other and requires master password for each block. Manually editing logins.json and putting IDs in order ({"id":1,...},{"id":2,...},{"id":3...} etc) solves the issue; remember also to adjust the block counter "nextId" to point to the next number in the first line. For the developers: this should give a hint as to where in the code it needs to be fixed, I hope. Should be really trivial.
(In reply to Oxana Smirnova from comment #247) > So, the problem lies in logins.json in user's profile and in the way it is > parsed. If for some reason block IDs "id" are not in a straight order and > have gaps (like, "id":2 is followed by "id":4 or such)... Forgot to mention: such gaps are probably created by users removing account records; this might explain difficulty in reproducing the bug, since not everybody removes accounts from a middle of a long list of such. If this is indeed the case, the developers should either make sure to re-order account IDs after removal, or to make the code ignoring the order (it shouldn't matter anyway, really).
Thank you for replying to this post. I have found my own solution to this problem. When you go into account options and then server options , you need to uncheck the box for "look for messages at startup". I did this with all my accounts and voila i get the Master Passwort Request only one time ! AS it's supposed to be. When there are new messages it will still load them somehow, idk why. I will say once again. I will not use a 3rd party tool that is handling my passwords. It is NOT secure. Some people even write in the comments how they gained more security by installing this StartupMaster, this is rediculous !! Nothing cuold be further from the truth. I hope i gave another clue on how to actually fix this important issue. Let me just point out why this is actually important: https://de.wikipedia.org/wiki/Kano-Modell . The dissatisfaction is greater then anything when something really basic doesn't work. I come to believe that at the time the source code was written (20 years ago) there was no problem. The knowledge how it works was lost during the years and now nobody knows how to fix the problem lol ! This Bug might even lead users to use weaker / shorter masterpasswords, because they need to enter it X-times. This is also dangerous. The more accounts you can manage with the software, the greater the value, normally. But in this case you just get another window. Prove me wrong and fix it ^^ . See it as a challange.
(In reply to Polar from comment #249) > Thank you for replying to this post. I have found my own solution to this > problem. When you go into account options and then server options , you need > to uncheck the box for "look for messages at startup". I did this with all > my accounts and voila i get the Master Passwort Request only one time ! AS > it's supposed to be. Thank you so much for the solution! You are completely right, its better not to use plugins for this. > When there are new messages it will still load them > somehow, idk why. It will still load them because of the "Allow immediate server notifications when new messages arrive" option in the "Server settings".
(In reply to Polar from comment #249) > Thank you for replying to this post. I have found my own solution to this > problem. When you go into account options and then server options , you need > to uncheck the box for "look for messages at startup". I did this with all > my accounts and voila i get the Master Passwort Request only one time ! AS > it's supposed to be. I have had Startup Master installed for some time, so I may have to go back and test this, but if I recall correctly, simply having multiple IMAP accounts does not cause the Master Password to be asked for multiple times. For me, it was when I added multiple Google Calendars. Tested: interesting, I have 8 IMAP accounts, and was asked for my MP twice. Confirmed 3 times. Still annoying, but not the end of the world scenario you are proclaiming it to be. I do know, though, that multiple Calendars can also trigger this problem. >> When there are new messages it will still load them somehow, idk why. > I will say once again. I will not use a 3rd party tool that is handling my > passwords. You are confused... Startup Master does not 'manage your passwords', it simply tries to actually fix the problem. It does not add to or take away from your 'security', it simply works around the annoyance. (In reply to Kirill from comment #250) > (In reply to Polar from comment #249) >> When there are new messages it will still load them >> somehow, idk why. > It will still load them because of the "Allow immediate server notifications > when new messages arrive" option in the "Server settings". Yes, this is called 'Idle' in IMAP nomenclature. I wish they would rename the setting or at least say 'aka 'Idle Support') The rest of your rant is counter productive. This bug is a minor annoyance with a simple workaround that works (for almost everyone).
(In reply to Charles from comment #251) > Tested: interesting, I have 8 IMAP accounts, and was asked for my MP twice. > Confirmed 3 times. Still annoying, but not the end of the world scenario you > are proclaiming it to be. Tested again after disabling only Lightning (Calendars), and even with 8 IMAP accounts, I only get one Master Password Prompt. So, your presumption that this is based on the number of IMAP accounts is wrong - or, you have some other Addon that is causing it for you.
(In reply to Charles from comment #251) > The rest of your rant is counter productive. This bug is a minor annoyance > with a simple workaround that works (for almost everyone). And you think it is acceptable that every Thunderbird has to be able to find and use this workaround? It is not. And please read Oxana Smirnovas comment #247 again.
(In reply to Moritz Franckenstein from comment #253) > (In reply to Charles from comment #251) >> The rest of your rant is counter productive. This bug is a minor annoyance >> with a simple workaround that works (for almost everyone). > And you think it is acceptable that every Thunderbird has to be able to find > and use this workaround? It is not. 1. It is nice that you are worrying about 'every Thunderbird user', but it really isn't your responsibility. 2. It isn't a matter of 'acceptability', it is a matter of reality. The reality is, this bug exists. The reality is, it hasn't been fixed yet. The reality is, there is a very simple workaround. > And please read Oxana Smirnovas comment #247 again. Maybe Oxana has hit upon a way to fix it (but maybe not) - in fact I really hope so, especially if it is easy. But, the reality is, I'm not a developer, so cannot confirm or deny it. It has only been one day since that was posted though, so let's give it some time. One thing I can do is post this to the Thunderbird support and dev lists, so maybe someone will pick it up and run with it (if it is in fact a/the solution)...
(In reply to Charles from comment #254) > 1. It is nice that you are worrying about 'every Thunderbird user', but it > really isn't your responsibility. Is it not? Then I would be wrong here. But this is not the customer support forum! This is exactly to help improve the product for 'every Thunderbird user', as I understand it.
(In reply to Moritz Franckenstein from comment #255) > This is exactly to help improve the product for 'every Thunderbird user', as > I understand it. Yes, it is, but complaining repeatedly and loudly, even to the point of rudeness to the developers, doesn't accomplish anything, and is, as I said, even COUNTER-productive. To get back to the matter at hand, I have to pose a question to Oxana (and others) in response to her (my apologies if I got the gender wrong) comment 247 and comment 248...
First, thanks very much Oxana for your investigative work in nailing this down! Question(s) below... (In reply to Oxana Smirnova from comment #248) > (In reply to Oxana Smirnova from comment #247) >> So, the problem lies in logins.json in user's profile and in the way it is >> parsed. If for some reason block IDs "id" are not in a straight order and >> have gaps (like, "id":2 is followed by "id":4 or such)... > > Forgot to mention: such gaps are probably created by users removing account > records; this might explain difficulty in reproducing the bug, since not > everybody removes accounts from a middle of a long list of such. If this is > indeed the case, the developers should either make sure to re-order account > IDs after removal, or to make the code ignoring the order (it shouldn't > matter anyway, really). Hi Oxana, Have you tested and confirmed that this fixes the problem for issues caused by all three factors: 1. Multiple IMAP accounts 2. Multiple Chat Accounts 3. Multiple Calendars I just tested one last time, and just disabling my calendars, but leaving Lightninig itself enabled, gets rid of the double prompt for me. So, I think that multiple IMAP accounts has nothing to do with it, it has to do with Calendar and Chat accounts - and maybe NEwsgroups (I don't use TB for newsgroups). So, the question is, does fixing that one file fix it for all use cases where the issue presents? I sure hope so... it seems like the fix will be easy, so now there is a good chance we can squash this one once and for all. Thanks again!
I'm following the debate as an affected but non-tech user: For info I dont have, and never have used Chat Accounts or Calendars but do suffer the multiple password issue. So I would have expected my profile to be "clean" of old Chat/Calendar accounts or spaces caused by deleting them. I do however have multiple (well, if 2 counts as multiple) IMAP accounts.
As has been said repeatedly by myself and others (see Comment #39, Comment #182, Comment #194, and Comment #209 as examples), this bug is a usability issue, and more seriously, a security issue. I've said it before, but it seems to bear repeating. I know sometimes developers are so used to the way their programs work, that it takes some adjustment to think like a novice user trying to learn the program, perhaps to decide if it is one the user wants to continue with or look for another. Getting multiple password prompts for no apparent reason is likely to cause one to think the program is not very well done. We know that's not the case, but users generally don't, especially new ones. TB developers: Who's your audience?
(In reply to Poohs from comment #258) > For info I dont have, and never have used Chat Accounts or Calendars but do > suffer the multiple password issue. So I would have expected my profile to > be "clean" of old Chat/Calendar accounts or spaces caused by deleting them. Did you check? > I do however have multiple (well, if 2 counts as multiple) IMAP accounts. I'd be very interested in details, because as I said, I have been unable to reproduce this problem with ONLY multiple IMAP accounts. (In reply to Tim Johnson from comment #259) > As has been said repeatedly by myself and others (see Comment #39, Comment > #182, Comment #194, and Comment #209 as examples), this bug is a usability > issue, and more seriously, a security issue. This bug is a usability issue, yes, definitely, but only for a limited number of people - remember, most (my opinion) people probably do not set a Master Password, so never encounter this problem. As for it being a security issue, I don't see any evidence supporting the conclusion that THIS bug is a security issue, but I do see evidence - and agree with it - that the dialog itself, being extremely vanilla in nature, needs some work. That said - all dialogs are subject to spoofing, so even if Mozilla created one very specific, there is nothing preventing a malicious hacker from spoofing that one too. The bottom line is, there is no such thing as a truly secure computer (that is usable for any practical purpose). Anyway, I posted about this to both the TB support and Dev lists, now lets see if Oxana's efforts will pay off.
(In reply to Charles from comment #257) > 3. Multiple Calendars > > I just tested one last time, and just disabling my calendars, but leaving > Lightninig itself enabled, gets rid of the double prompt for me. Sorry, failed to specify, this problem only occurs for REMOTE calendars (ie, Google Calendars, etc), not Local (local on the computer only) calendars.
(In reply to Charles from comment #257) > > ... > Have you tested and confirmed that this fixes the problem for issues caused > by all three factors: > Hi Charles, the file logins.json is essentially a database with all Thunbderbird passwords, and you will see them if you go to Thunderbird's Preferences->Secutrity->Passwords->Saved Passwords, so no magic here :-) And yes, these are all passwords, for all possible accounts, including IMAP, SMTP, XMPP, calendars and whatever Thunderbird can handle. The easiest fix is actually just to delete the logins.json file, and re-enter all the needed passwords again: this will re-create a clutter-free file a-new. Make sure to take note of all your passwords before deleting it though (click "Saved Passwords..." as indicated above and "Show passwords" therein). And my fix from comment #247 is good for several IMAP and SMTP passwords, but aparently not always enough, as the file logins.json can aparently get corrupted in some other ways which I am yet to find. I have an old profile with 39 (!) passwords from all sorts of services, and it is a big mess to fix. I am down to only 4 master password prompts now, way better than 39 :-) Other fixes proposed in this thread do not fix the corrupt or cluttered file, they simply reduce number of requests to it and hence the number of unnecessary master password prompts. All in all, we seem to be dealing with a kind of a mild database corruption. I am not a developer, but since some corruption happens now and then, Thunderbird developers should perhaps think of how to treat it gracefully, without spawning additional password prompts. Just a guess, perhaps Thunderbird tries to re-load the logins.json file every time it stumbles upon an unreadable record in it?
(In reply to Charles from comment #257) > > ... > Have you tested and confirmed that this fixes the problem for issues caused > by all three factors: > Hi Charles, the file logins.json is essentially a database with all Thunbderbird passwords, and you will see them if you go to Thunderbird's Preferences->Secutrity->Passwords->Saved Passwords, so no magic here :-) And yes, these are all passwords, for all possible accounts, including IMAP, SMTP, XMPP, calendars and whatever Thunderbird can handle. The easiest fix is actually just to delete the logins.json file, and re-enter all the needed passwords again: this will re-create a clutter-free file a-new. Make sure to take note of all your passwords before deleting it though (click "Saved Passwords..." as indicated above and "Show passwords" therein). And my fix from comment #247 is good for several IMAP and SMTP passwords, but aparently not always enough, as the file logins.json can aparently get corrupted in some other ways which I am yet to find. I have an old profile with 39 (!) passwords from all sorts of services, and it is a big mess to fix. I am down to only 4 master password prompts now, way better than 39 :-) Other fixes proposed in this thread do not fix the corrupt or cluttered file, they simply reduce number of requests to it and hence the number of unnecessary master password prompts. All in all, we seem to be dealing with a kind of a mild database corruption. I am not a developer, but since some corruption happens now and then, Thunderbird developers should perhaps think of how to treat it gracefully, without spawning additional password prompts. Just a guess, perhaps Thunderbird tries to re-load the logins.json file every time it stumbles upon an unreadable record in it?
It's not only a problem in Thunderbird, but also in Firefox. Even the actual release 49.0.2 shows this behaviour, so solving it in some login.js or so won't fix the problem in Firefox. Well, who expects, that a bug would be fixed after only 14 years... :-(
(In reply to Charles from comment #260) > > I'd be very interested in details, because as I said, I have been unable to > reproduce this problem with ONLY multiple IMAP accounts. I have 2 IMAP accounts, a "Local Folders" "account" plus the "Outgoing Server" configured in my tb. So that sounds to be like exclusively 2 IMAP accounts. I get 4 prompts for my Master Password every time I login. What additional details can I provide to you? My logins.json file looks like this: { "logins" : [ { "id" : 1, ... }, { "id" : 3, ... }, { "id" : 4, ... }, { "id" : 6, ... }, { "id" : 7, ... }, "nextId" : 8 } I get 4 Master Password prompts, but I only see 2 discontinuities in the ids in my logins.json file (1->3 and 4->6).
(In reply to Oxana Smirnova from comment #263) > The easiest fix is actually just to delete the logins.json file, and > re-enter all the needed passwords again: this will re-create a clutter-free > file a-new. Make sure to take note of all your passwords before deleting it > though (click "Saved Passwords..." as indicated above and "Show passwords" > therein). My ids are in order, but with gaps in the numbering. I edited my logins.json file and simply replaced all of the ids with 1, 2, 3, etc. and adjusted the "nextId" value as well. I started tb again and I'm still getting 4 prompts. I removed my logins.json file and re-entered all my passwords. I'm down to 3 prompts, now (plus the prompt to install the Osaka font... love that one, too). So neither re-numbering the logins nor destroying my logins.json file has solved this problem for me.
(In reply to Polar from comment #249) > Thank you for replying to this post. I have found my own solution to this > problem. When you go into account options and then server options , you need > to uncheck the box for "look for messages at startup". I did this with all > my accounts and voila i get the Master Passwort Request only one time ! AS > it's supposed to be. When there are new messages it will still load them > somehow, idk why. > Thanks! This works for me on both Windows and Linux: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 I did several tests & validated the login.json files - in fact I tested with deleted login.json files and still received multiple password prompts. My current login.json ID's are all in order (all 108 of them) so I can not verify if them being out of order causes an issue or not. I also tested by using the logins.json from SeaMonkey, and the Windows Thunderbird logins.json in linux etc. IMO this bug is most likely caused by a race condition as mentioned by Tobias & others. Note that I cannot replicate in any recent SeaMonkey (linux or Windows). Both SeaMonkey and Thunderbird have the same calendars (including syncing with Google Calendar), exact same email accounts, I've interchanged the logins.json from Tunderbird, and still cannot replicate even though I believe that Thunderbird & SeaMonkey use the same/similar code.
(In reply to Charles from comment #260) > (In reply to Poohs from comment #258) > > For info I dont have, and never have used Chat Accounts or Calendars but do > > suffer the multiple password issue. So I would have expected my profile to > > be "clean" of old Chat/Calendar accounts or spaces caused by deleting them. > > Did you check? > > > I do however have multiple (well, if 2 counts as multiple) IMAP accounts. > > I'd be very interested in details, because as I said, I have been unable to > reproduce this problem with ONLY multiple IMAP accounts. > > (In reply to Tim Johnson from comment #259) > > As has been said repeatedly by myself and others (see Comment #39, Comment > > #182, Comment #194, and Comment #209 as examples), this bug is a usability > > issue, and more seriously, a security issue. > > This bug is a usability issue, yes, definitely, but only for a limited > number of people - remember, most (my opinion) people probably do not set a > Master Password, so never encounter this problem. > > As for it being a security issue, I don't see any evidence supporting the > conclusion that THIS bug is a security issue, but I do see evidence - and > agree with it - that the dialog itself, being extremely vanilla in nature, > needs some work. > > That said - all dialogs are subject to spoofing, so even if Mozilla created > one very specific, there is nothing preventing a malicious hacker from > spoofing that one too. > > The bottom line is, there is no such thing as a truly secure computer (that > is usable for any practical purpose). > > Anyway, I posted about this to both the TB support and Dev lists, now lets > see if Oxana's efforts will pay off. Charles, your efforts are appreciated. We disagree on a few things. I doubt anyone has a handle on how many TB users use a master password. It is probably not as many as those who use Firefox, however, since they are very likely to use stored passwords for various accounts they browse to. Remember, this bug affects both TB and Firefox. Regardless whether you don't see this as a security issue, many commenters to this bug do. This is not because of faulty code in the core product component (PSM), but in the workaround that is being used as an excuse not to put resources on this bug. I say excuse not to denigrate the developers, I have only admiration for what they have done with limited resources, but after something like 14 years I don't know what else to call it. We agree that it is pretty hard, if not impossible, to make any software 100% secure from spoofing. But given a choice between integrated code reviewed by the developers, and a third party add-on, I'll trust the integrated code every time. I've had success with Polar's workaround (Comment #249) with TB. It also has its drawbacks in that the messages must be requested on start-up. I haven't tested if this is also true when coming out of hibernation. This may be a reasonable solution for most TB users, but one that Mozilla should document clearly because it is definitely not obvious. If it can be documented right in the tools->account-?server settings UI the better.1
I recall that SeaMonkey also experienced this issue a few years back; here is the bug report that fixed the issue: https://bugzilla.mozilla.org/show_bug.cgi?id=381269 Bug 381269 - Multiple simultaneous master password prompts when checking multiple imap accounts on startup Perhaps the Thunderbird devs can take a look to see if the modifications that were done in SeaMonkey can be/are used in Thunderbird?
Well, I once also had this problem. However, for a long time now, all is fine, and still I only get a single Master Password prompt in both firefox and thunderbird. After the discussion here, I had a look at my logins.json files. Unfortunately, I have to tell that my logins.json in thunderbird does have gaps: 1, 4, 5, 6, 8, 9, 10. And still this does *not* lead to multiple prompts. Seems, it's more complicated...
(In reply to Christopher Schultz from comment #266) > My ids are in order, but with gaps in the numbering. I edited my logins.json > file and simply replaced all of the ids with 1, 2, 3, etc. and adjusted the > "nextId" value as well. I started tb again and I'm still getting 4 prompts. > > I removed my logins.json file and re-entered all my passwords. I'm down to 3 > prompts, now (plus the prompt to install the Osaka font... love that one, > too). > > So neither re-numbering the logins nor destroying my logins.json file has > solved this problem for me. Bummer... not sure why it apparently worked for Oxana, but it seems this was a red herring.
(In reply to Charles from comment #271) > > Bummer... not sure why it apparently worked for Oxana, but it seems this was > a red herring. There ought to be something else, it really worked for me in 5 different Thunderbird instances, but I must admit I still struggle with the case mentioned in comment #263. It could be that key3.db and cert8.db also need a clean-up, but those are "real" databases and can't be edited easily. I wonder how many people on this thread use password-protectedd digital certificates? I wish we can get a developer of this piece of code to this thread; so far we're blindly poking here and there. Even if Thunderbird is a self-supported community software, I would hope that the original developers are a part of this community. My naive understanding is that the Master Password is needed to "unlock" access to logins.json and key3.db, and hence is requested every time these files are accessed. Normally, this authorisation should be cached, or the files should be loaded once per Thunderbird session and stored in memory, and I don't know what Thunderbird is actually doing in this respect. Whatever the approach might be, it obviously breaks at some point, and this can probably be triggered by different conditions or combinations of such. Perhaps numbering gaps in logins.json alone are not enough to trigger the problem, maybe there's something else.
(In reply to Tim Johnson from comment #268) > I doubt anyone has a handle on how many TB users use a master password. It > is probably not as many as those who use Firefox, however, since they are > very likely to use stored passwords for various accounts they browse to. > Remember, this bug affects both TB and Firefox. Yes, but this bug is for Thunderbird, not Firefox, and they (the bugs) likely are different. For one thing, I have never seen this problem for just IMAP accounts, in my experience it only happens when you also have one or more remote calendars. > I've had success with Polar's workaround (Comment #249) with TB. It also has > its drawbacks in that the messages must be requested on start-up. Not if the server in question supports IDLE and you have it enabled in TB (it is by default I believe). With IDLE, you just disable both 'Check on Startup' and 'Check every X minutes' and let the server handle the notifications. > This may be a reasonable solution for most TB users, but one that Mozilla > should document clearly because it is definitely not obvious. If it can be > documented right in the tools->account-?server settings UI the better. I agree, but... as I have said repeatedly, I have always had numerous IMAP accounts, and I have never seen this bug occur without Lightning (+ at least one Remote Calendar) being involved. Someone else said that Chat accounts would also trigger it but I would never know about that (don't use TB for chat). Personally, I think it is something related to the combination. It is interesting though that simply unchecking the 'Check at Startup' option eliminates the problem... and this should be telling for a developer who might look into this someday.
(In reply to Oxana Smirnova from comment #272) > There ought to be something else, it really worked for me in 5 different > Thunderbird instances, but I must admit I still struggle with the case > mentioned in comment #263. It could be that key3.db and cert8.db also need a > clean-up, but those are "real" databases and can't be edited easily. key3.db is a sqlite database, but it's encrypted -- presumably with your master password. I haven't figured out how to crack into it yet, as the 'sqlite3' CLI doesn't seem to support passwords/encryption. It sees that the database is encrypted, but it doesn't support decryption. We might need another program to open it.
(In reply to Charles from comment #273) > It is interesting though that simply unchecking the 'Check at Startup' > option eliminates the problem... and this should be telling for a developer > who might look into this someday. I have two IMAP accounts. I set both of them to NOT "Check for new messages on startup", and I *still* get two "Master Password" prompts at startup. I have no calendars enabled AFAIK. One of my IMAP accounts is a Google account, if that changes anything. I have the Lightning add-on installed (because everybody gets it, now, I guess) but I opted-out of its use when it first appeared. The add-on itself is currently enabled. My other add-ons are Adblock Plus, Enigmail, and LookOut (a TNEF attachment reader). I don't believe any of those would trigger a Master Password prompt. The good news about the multiple password prompts is that you only actually need to enter your password into one of them. I use keepass/x, so I just drag-drop my master password into the active dialog and press ENTER, then ESC ESC ESC and the superfluous dialogs go away and I'm okay. It's still annoying.
(In reply to Christopher Schultz from comment #275) > I have the Lightning add-on installed (because everybody gets it, now, I > guess) but I opted-out of its use when it first appeared. The add-on itself > is currently enabled. I am sure that the release with built-in Lightning triggered the multiple propmts for me, I actually tested it. Of course, there were other changes in that release, not just Lightning, but it does look very much related. And no, I never had calendar accounts and never configured Lightning. Now, I have Lightning fully disabled and removed, and re-created logins.json, and happily down to just one Master Password prompt. > > The good news about the multiple password prompts is that you only actually > need to enter your password into one of them. Not in my case, sadly, I definitely had to enter it again for XMPP accounts, and probably even for IMAP accounts on different servers, not sure now and didn't keep a record.
(In reply to Charles from comment #273) > (In reply to Tim Johnson from comment #268) > > Remember, this bug affects both TB and Firefox. > > Yes, but this bug is for Thunderbird, not Firefox, and they (the bugs) > likely are different. Charles, check the Product/Component information in the bug header. The product is "core". At least the developers believe this is for both. Also search for "firefox" in this bug, and you will see the issue affects it as well. > It is interesting though that simply unchecking the 'Check at Startup' > option eliminates the problem... and this should be telling for a developer > who might look into this someday. Charles, I agree, and I believe this is most likely due to the start-up check for messages and the calendar initialization occur in two separate threads. Each spun off at about the same time. Further, and this has been suggested by others in this bug, I believe there is no blocking action taken when the first thread that gets to where it needs the master password. If there was, other threads which also need the master password would wait until the block was cleared, and as they proceed, they would see the password had already been accepted assuming a flag to indicate such was set by the first thread. This is usually accomplished by mutex signaling which will ensure that only one thread at a time can affect the state of the flag. For myself and TB, I never had the multiple password prompt until the release that made Lightning a part of the build, and I installed my Google calendar.
(In reply to Tim Johnson from comment #277) > … > > It is interesting though that simply unchecking the 'Check at Startup' > > option eliminates the problem... and this should be telling for a developer > > who might look into this someday. > > Charles, I agree, and I believe this is most likely due to the start-up > check for messages and the calendar initialization occur in two separate > threads. Each spun off at about the same time. Further, and this has been > suggested by others in this bug, I believe there is no blocking action taken > when the first thread that gets to where it needs the master password. If > there was, other threads which also need the master password would wait > until the block was cleared, and as they proceed, they would see the > password had already been accepted assuming a flag to indicate such was set > by the first thread. This is usually accomplished by mutex signaling which > will ensure that only one thread at a time can affect the state of the flag. I think there is something wrong in *when* Thunderbird prompts for the master password. What I've noticed is that TB wants to log in, sends the username, then sees that it needs a password, request the master password and then sends the password. This scenario fails when you wait a while before entering the master password: you get all sorts of timeouts and errors. It would be better if Thunderbird would check up front if it needs a password or would ask for it at startup time anyway (like it does with the StartupMaster add-on installed).
(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #278) > It would be better if Thunderbird would check up front if it needs a > password or would ask for it at startup time anyway (like it does with the > StartupMaster add-on installed). Yes, I think StartupMaster runs before the relevant password requiring threads are started. By the time they do, the password has already been acquired. If the Mozilla products would move their password prompt to roughly the same place, I think that would solve the problem.
(In reply to NoOp from comment #234) > I can confirm the results of Comments 179 & 180: > > Name Thunderbird > Version 45.0 > User Agent Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 > Thunderbird/45.0 > Application Build ID 20160407161913 > Lightning 4.7 true {e2fda1a4-762b-4020-b5ad-a41df1933103} > > With Lightning enabled I get 8 password prompts -- if I disable Lightning I > get one prompt. So I tested further and enabled Lightning again, but > disabled Provider for Google Calendar 2.7 > (a62ef8ec-5fdc-40c2-873c-223b8a6925cc} - I now only get 1 Master Password > prompt. > > I use the same addon in SeaMonkey (Windows and Linux) and do not experience > the same. > My problem appears to be: https://bugzilla.mozilla.org/show_bug.cgi?id=833272 For me, Lightning is disabled but I still get many password prompts: ====== Nom Icedove Version 45.4.0 ====== Extensions Nom Version Activée ID LaTeX It! 0.6.2 true tblatex@xulforum.org Iceowl 4.7.4 false {e2fda1a4-762b-4020-b5ad-a41df1933103}
I believe we have a simple race condition here: - Thread A needs a password - Thread A check if there is already a dialog - no - Thread B needs a password - Thread B check if there is already a dialog - no - Thread C needs a password - Thread A opens the dialog a - Thread C check if there is already a dialog - yes - Thread B opens the dialog b - Thread C blocks - User enters password to b (because this one is on top) - Thread B continues - Thread C continues because password is now ready - User still sees dialog a - User enters password to a - Thread A continues
Based on the behavior I see, the threads are not checking for a dialog, they are checking whether the master password has been entered.
Yes, Daniel, this threading issue is the key. In the meantime, I've written some summary for this bug as lots of details were lost in the previous comments. === What is this bug about? === Mozilla products (Firefox/Thunderbird/Seamonkey/etc.) display more than one master password prompts simultaneously under certain circumstances. The actual circumstances vary between users, products, operating systems etc., which makes the bug difficult to reliably reproduce. The most common cases were fixed using symptomatic treatments during the last 14 years, but it resurfaced later under different circumstances. === Why do we have several master password prompts? === First we have to understand the general picture on how master passwords in Mozilla products work. The client applications (such as Firefox or Thunderbird) contain a common set of features called the Mozilla core. Mozilla core has a security subsystem called PSM (Personal Security Manager) that deals with cryptographic operations on behalf of the client application. For instance, setting up a secure connection to a server or verifying that an add-on hasn't been tampered with. Some of these operations are related to credential storage. Credentials are username/password combinations, access tokens or client certificates. For our purposes, we may consider the latter two as very long passwords. Mozilla implements an international standard called PKCS11 for the secure storage of credentials. PKCS11 has the concept of security devices. A security device can be a smart card reader, a central server in an organization or a password manager installed on your computer. Mozilla core contains a built-in one called the Software Security Device that encrypts your credentials using a single master password and stores them in your profile folder. Apart from that, you can install external modules (such as one from a smart card vendor) that add their own security devices. Let's consider an example. When you start Thunderbird, it will check for new messages on startup. It connects to your mail provider, which will request a password (or some other form of credential). Thunderbird will query the PSM for a stored password. Thunderbird doesn't know, and doesn't have to know if the password is stored on a smart card, on a company server or encrypted with a master password. The PSM will pick the appropriate security device. In our case, it will be the Software Security Device. It checks if the device is available and ready. The Software Security Device is always available but it won't be ready as we haven't supplied the master password yet. The PSM then invokes the login method of the device. Again, this varies by device, e.g. it can request a PIN code or a fingerprint on a smart card reader, but in our case it will pop up a dialog asking for the master password. Once the correct master password is supplied, the device sets its status to ready and returns the decrypted credential to the client application, in our case Thunderbird. Connecting to a server and fetching messages takes time. We would like Thunderbird to remain responsive during this period. We expect modern software to do such operations in the background so that we can still scroll previous messages or write a new one in the meanwhile. The operating system (such as Windows) provides a feature called threads that help us achieve this. A program using two threads can perform two operations at the same time. If we are fetching mail from several providers or accounts, we can speed it up by using a separate thread for each of them. The main thread is reserved for the user interface (such as drawing dialogs or processing clicks and keypresses). These threads are running independently and in parallel. One of the threads connects to the server to retrieve messages, is asked for login credentials, queries the PSM, displays a master password prompt. In the meantime, another thread connects to a different server, is asked for login credentials, queries the PSM and finds that it's not ready yet, so it displays another master password prompt. The two threads need to communicate with each other to avoid this kind of situation. For the typical case of multiple e-mail accounts described above, the problem has already been fixed. But it may still resurface, for instance, when an e-mail fetch clashes with a calendar synchronization or a chat login or a proxy authentication or an add-on using stored credentials to connect to a remote service or whatever. The main issue is that the Software Security Device is not properly multithreaded. === How can we fix the multiple password prompt issue? === First of all, any patches to the Firefox or Thunderbird client codebase will only be of symptomatic nature. To fix the issue once and for all, we need to address the Software Security Device itself. That's why this bug is filed in "Product: Core, Component: Security: PSM". Threads can communicate with each other using synchronization primitives (such as critical sections, locks, mutexes and semaphores). Let's ignore the differences for now and say that these primitives allow a thread to say "I want exclusive access to this security device now; if you also want to use it, wait until I'm finished". My solution would be to take the code fragment responsible for checking whether we are logged into the security device and showing the master password dialog if we aren't, and wrap it in a critical section. For developers, I think it's the if-block containing the call to PK11_DoPassword in the function PK11_Authenticate. Please note that I am not feeling competent enough to assess the side effects of such a change. === Why is it so complicated? Why does it take so long? === On one hand, we need a developer who - knows the way around the Mozilla codebase - has the skills and experience to work with security-related code - has the skills and experience to work with multithreaded code where the last two requirements are highly nontrivial. The difficulty in security-related and multithreaded programming is not that it's too technical but that it's too easy to introduce intermittent bugs that are hard to spot. Here are some fictional examples: - By using shared memory between security devices, we allow a malicious security device to extract passwords from another one. - We inadvertantly introduce a race condition where two threads are mutually waiting for each other, resulting in a deadlock on x86 Linux machines with two processors and the bfs scheduler. - We break FIPS certification and realize 10000 revisions later when it's too late to roll back and Mozilla has to pay $$$ for a new audit. Yes, I'm exaggerating. We probably won't have such issues. But the point is that we do need an expert. On the other hand, let's be frank, this bug doesn't affect too many people. Most users don't have a master password at all. For the majority of those who do, it just works - thanks to the hotfixes done so far. Even if it doesn't, the chances are high that they can work it around using StartupMaster. I would guess that there are roughly 1000 people who are actually affected. Again, I'm not saying that it shouldn't be fixed. I'm just saying that if a random Mozilla developer bumps into this bug, he'll spend a few minutes looking at it and then change to a different bug that is easier to fix and affects more people. === How can I help to make sure this bug is fixed ASAP? === - Ask around on IRC or the mailing list for Mozilla developers with both security & multithreading related experience. Point them to this comment. - Set up a bounty. - Vote for the bug. - Avoid adding unnecessary comments to the discussion. === Are there any workarounds? === StartupMaster fixes the issue for most users. You can download it here: For Firefox: https://addons.mozilla.org/en-US/firefox/addon/startupmaster For Thunderbird: https://addons.mozilla.org/en-US/thunderbird/addon/startupmaster/ (Disclaimer: I am the author.) === How does StartupMaster work? === It activates during Firefox/Thunderbird startup, before the usual password requests. Asks the PSM to log in to the Software Security Device. At this point the client code is single threaded, so it locks up the main thread, preventing the application from starting and popping up further dialogs. Once the master password is supplied, the device state becomes ready, so by the time the other threads start requesting credentials, no further password prompts will be necessary. === Is StartupMaster secure? === I strive to keep it at least as secure as the Mozilla code itself. - StartupMaster never works with passwords, just calls functions from Mozilla core. - The full source code is around 300 lines, with comments to make it easier to read. - It was reviewed several times by Mozilla employees. - I only change when necessary for compatibility reasons. There were 5 published versions in 7.5 years. - I almost always turn down feature requests, aiming for simplicity. StartupMaster doesn't add any security to Mozilla. It doesn't protect your browser or mail client as it can be disabled by starting in safe mode. But it doesn't take away any security either. Consider it as a convenience add-on that was built with security in mind. === Can StartupMaster's functionality be added into Mozilla core? === Maybe. I still consider the solution with cross-thread synchronization mentioned above to be cleaner.
(In reply to Tamas Hubai (:htamas) from comment #283) Many thanks, Tamas, finally somebody knowledgeable paid attention! > === How can I help to make sure this bug is fixed ASAP? === > > - Ask around on IRC or the mailing list for Mozilla developers with both > security & multithreading related experience. Point them to this comment. Oh, I naively thought that Bugzilla is meant to point developers to bugs, but if it is avoided by the developers, could you please be more specific where can I bug them? Where is the IRC and the mailing list? > - Set up a bounty. I promise a beer to whoever fixes it, really! Where shall I announce it? > - Vote for the bug. Did that > - Avoid adding unnecessary comments to the discussion. I wish I knew which comments are necessary and which are not; I realise that all the time I spent trying to chase and fix the problem is in vain, but hey, you wrote a very nice summary after all the silly comments of ours! > === Can StartupMaster's functionality be added into Mozilla core? === > > Maybe. I still consider the solution with cross-thread synchronization > mentioned above to be cleaner. Agree. I only wonder why this race condition did not show up before bundling Lightning into Thunderbird?
I just came by today, to say happy birthday, as this bug turns 14 today (in my timezone).. Tamas, thank you very much for your really great summary! (comment #283) It's really a pleasure to read once exactly, what's going on, after years of false assumptions (related only to google calendar provider, etc.), through several duplicated Bugs (meanwhile collected in one meta-bug: https://bugzilla.mozilla.org/show_bug.cgi?id=570421), searching for a solution / a _working_ workaround. As for the workaround "StartupMaster", i wanted to add, i've tried that 2 years ago, and i'm sorry to say, that it completely fubared my thunderbird installation, so much, i had to reinstall.
(In reply to eular.frank from comment #280) > For me, Lightning is disabled but I still get many password prompts: What about Chat accounts? If you don't have any, is it still enabled? Tools > Options > Chat I have 'When Thunderbird starts:' set to 'Keep my Chat Accounts offline' and everything else disabled.
(In reply to Oxana Smirnova from comment #276) > Not in my case, sadly, I definitely had to enter it again for XMPP accounts, > and probably even for IMAP accounts on different servers, not sure now and > didn't keep a record. There are 4 types of native 'Accounts' in TB: Mail, Chat, Feed (RSS), and Newsgroup. A fifth (Calendar) is added when Lightning is installed, which is now done by default. I have never experienced this problem with ONLY mail/IMAP accounts, so it seems the race condition described above is only triggered whenever one or more additional account types are involved. So, anyone who is experiencing this problem should be taking these additional accounts into consideration when testing. I know that Mail, Chat and Newsgroup accounts require AUTH (usernames/passwords), but I don't use RSS feeds - do these require AUTH?
(In reply to Christopher Schultz from comment #275) > My other add-ons are Adblock Plus, Enigmail, and LookOut Actually, I think Enigmail might... doesn't it require it also have to AUTH to something?
(In reply to Tamas Hubai (:htamas) from comment #283) > === Can StartupMaster's functionality be added into Mozilla core? === > > Maybe. I still consider the solution with cross-thread synchronization > mentioned above to be cleaner. Thanks VERY much Tamas for taking the time to summarize this issue so well. I would only add two things... 1. As I said above, I now believe pretty strongly that this issue only presents when there is at least one Mail Account type, and one *other* type - Chat, Feed, Newsgroup, Calendar, and/or probably Enigmail. It may or may not present if there are NO mail accounts, but who would use TB for *only* other account types? and 2. I believe that regardless of whether or not there is a 'better' way to fix this in the long run, in the short run, since Startup Master has more proven to be an effective workaround, it should be integrated into the Core code asap, so I opened bug 1313658 in hopes this might get some traction after all the activity this bug has seen in the last few days.
(In reply to Oxana Smirnova from comment #284) > (In reply to Tamas Hubai (:htamas) from comment #283) > Many thanks, Tamas, finally somebody knowledgeable paid attention! > >> === How can I help to make sure this bug is fixed ASAP? === >> >> - Ask around on IRC or the mailing list for Mozilla developers with both >> security & multithreading related experience. Point them to this comment. > > Oh, I naively thought that Bugzilla is meant to point developers to bugs, > but if it is avoided by the developers, could you please be more specific > where can I bug them? Where is the IRC and the mailing list? Well, take a look at all of the comments in this bug. Do you really expect volunteers to wade through the morass of comments, often rude and demanding whining about the bug not being fixed? As non developers, one way we can help is to try to cut through this morass for the devs actually willing to do the coding. That is all Tamas meant. >> - Avoid adding unnecessary comments to the discussion. > > I wish I knew which comments are necessary and which are not; I realise that > all the time I spent trying to chase and fix the problem is in vain, but > hey, you wrote a very nice summary after all the silly comments of ours! ?? I think it was an excellent summary. I'm not dismissing your attempts either, they are certainly appreciated, and more importantly, spurred a lot more valuable input. Alas, it appears you were wrong about what appeared on the surface to be an easy fix - it just didn't work for others. No one is blaming you, but it is the reality. > Agree. I only wonder why this race condition did not show up before bundling > Lightning into Thunderbird? Because, I believe, it only happens when multiple account TYPES are involved that require AUTH... That said, if you really didn't have a remote calendar defined (one that would require AUTH), and/or didn't set up one of the others (newsgroup, chat, etc), and truly only have mail accounts, then I don't know why you were getting multiple prompts. My tests showed that simply disabling the Remote Calendars was enough to eliminate the multiple prompts. That said, I'm going to go test again. I was tired when I did those tests, maybe I did something wrong.
(In reply to Charles from comment #260) > (In reply to Poohs from comment #258) > > For info I dont have, and never have used Chat Accounts or Calendars but do > > suffer the multiple password issue. So I would have expected my profile to > > be "clean" of old Chat/Calendar accounts or spaces caused by deleting them. > > Did you check? > > > I do however have multiple (well, if 2 counts as multiple) IMAP accounts. > > I'd be very interested in details, because as I said, I have been unable to > reproduce this problem with ONLY multiple IMAP accounts. > > (In reply to Tim Johnson from comment #259) > > As has been said repeatedly by myself and others (see Comment #39, Comment > > #182, Comment #194, and Comment #209 as examples), this bug is a usability > > issue, and more seriously, a security issue. > > This bug is a usability issue, yes, definitely, but only for a limited > number of people - remember, most (my opinion) people probably do not set a > Master Password, so never encounter this problem. > > As for it being a security issue, I don't see any evidence supporting the > conclusion that THIS bug is a security issue, but I do see evidence - and > agree with it - that the dialog itself, being extremely vanilla in nature, > needs some work. > > That said - all dialogs are subject to spoofing, so even if Mozilla created > one very specific, there is nothing preventing a malicious hacker from > spoofing that one too. > > The bottom line is, there is no such thing as a truly secure computer (that > is usable for any practical purpose). > > Anyway, I posted about this to both the TB support and Dev lists, now lets > see if Oxana's efforts will pay off. For Charles re his comment 260: Firstly, appologies for the delay - I only have a casual interest in this thread as the work around works fine for me, so I read these comments as and when the mood grabs me ! I hadnt checked my logins.json file but I have now and it is clean with no breaks and 3 x IDs in numerical order. The three accounts = two IMAP accounts and one POP. As I said before, I have never used TB for Chat/News/Calandar or anything else. Is this enough detail for you ? If not, let me know what else you'd like. Maybe the POP account is "the other account type" causing the problem for me ? I suppose I'm a bit of a dinasaur now still using POP but this POP account is a very, very old account (pre 2000) and I cant find IMAP settings for it.
(In reply to Poohs from comment #291) > I hadnt checked my logins.json file but I have now and it is clean with no > breaks and 3 x IDs in numerical order. The three accounts = two IMAP > accounts and one POP. As I said before, I have never used TB for > Chat/News/Calandar or anything else. And as someone who has been supporting end users (professionally and personally for family and friends) for 30 some odd years, I can safely say it is not uncommon that when someone says something like this it turns out they had forgotten about one or another... So, have you actually checked and confirmed? 1. Make sure Lightning is disabled (you said you weren't using it) 2. Make sure that all things Chat related are disabled (see my previous) 3. Make sure you have no newsgroups defined (not likely you would have missed this because they would be showing up in your Accounts pane) 4. Make sure you have no RSS feeds defined (same as for newsgroups) > Maybe the POP account is "the other account type" causing the problem for me > ? I suppose I'm a bit of a dinasaur now still using POP but this POP > account is a very, very old account (pre 2000) and I cant find IMAP settings > for it. For an account like that, if I had/wanted to keep it, I'd just set up one of my others to pull those messages down and dump them into a folder.
(In reply to Charles from comment #289) > 1. As I said above, I now believe pretty strongly that this issue only > presents when there is at least one Mail Account type, and one *other* type > - Chat, Feed, Newsgroup, Calendar, and/or probably Enigmail. It may or may > not present if there are NO mail accounts, but who would use TB for *only* > other account types? What you believe does not match up with my experience. I have only IMAP (and SMTP for outgoing, but I'm not being asked for that on startup) accounts and I have this issue. I'm not going to mention it again because (a) I've already said it many times and (b) this bug has enough idle chatter in it. The only thing left to do is get the attention of someone competent to fix it. Honestly, identifying the variety of account types is a red herring, so let's please stop perseverating upon it. > 2. I believe that regardless of whether or not there is a 'better' way to > fix this in the long run, in the short run, since Startup Master has more > proven to be an effective workaround, it should be integrated into the Core > code asap, so I opened bug 1313658 in hopes this might get some traction > after all the activity this bug has seen in the last few days. I have no actual karma here, but I'm -1 on this suggestion. There's no reason why this shouldn't be fixed the "right way". Assuming that the Software Security Device is at least multi-threaded SAFE (that is, no data will be destroyed by any lack of multi-threaded interactions) right now, it should be made multi-threaded USEFUL so things like this do not crop-up and annoy the hell out of users.
(In reply to Christopher Schultz from comment #293) > (In reply to Charles from comment #289) > > 1. As I said above, I now believe pretty strongly that this issue only > > presents when there is at least one Mail Account type, and one *other* type > > - Chat, Feed, Newsgroup, Calendar, and/or probably Enigmail. It may or may > > not present if there are NO mail accounts, but who would use TB for *only* > > other account types? > > What you believe does not match up with my experience. As I said, I'll be retesting this again later. >> 2. I believe that regardless of whether or not there is a 'better' way to >> fix this in the long run, in the short run, since Startup Master has more >> proven to be an effective workaround, it should be integrated into the Core >> code asap, so I opened bug 1313658 in hopes this might get some traction >> after all the activity this bug has seen in the last few days. > > I have no actual karma here, but I'm -1 on this suggestion. There's no > reason why this shouldn't be fixed the "right way". There are three (four?) very big reasons... 1. This fix is already done - just a matter of incorporating it. 2. It works. 3. The 'right way' still has yet to even be defined, let alone scoped. 4. In light of #3, it is likely (and some chatter here supports this) that it will be difficult to do this the 'right' way, otherwise it would have been fixed by now.
(In reply to Charles from comment #292) > (In reply to Poohs from comment #291) > > I hadnt checked my logins.json file but I have now and it is clean with no > > breaks and 3 x IDs in numerical order. The three accounts = two IMAP > > accounts and one POP. As I said before, I have never used TB for > > Chat/News/Calandar or anything else. > > And as someone who has been supporting end users (professionally and > personally for family and friends) for 30 some odd years, I can safely say > it is not uncommon that when someone says something like this it turns out > they had forgotten about one or another... > > So, have you actually checked and confirmed? > > 1. Make sure Lightning is disabled (you said you weren't using it) > > 2. Make sure that all things Chat related are disabled (see my previous) > > 3. Make sure you have no newsgroups defined (not likely you would have > missed this because they would be showing up in your Accounts pane) > > 4. Make sure you have no RSS feeds defined (same as for newsgroups) > > > Maybe the POP account is "the other account type" causing the problem for me > > ? I suppose I'm a bit of a dinasaur now still using POP but this POP > > account is a very, very old account (pre 2000) and I cant find IMAP settings > > for it. > > For an account like that, if I had/wanted to keep it, I'd just set up one of > my others to pull those messages down and dump them into a folder. Hi Charles, 1. Lightning is definitely disabled - I removed the Lightning Add-on altogether from TB as soon as it was "forcefully" installed. 2. I have zero Chat accounts set-up and never have had any. Looking in Options/Chat I cant see a way of disabling it, if there is can you please point it out to me. 3 & 4. I have zero News Groups and zero RSS feeds set up and never have had any. Thanks for the suggestion re my old POP account.
See comment 286
(In reply to Charles from comment #296) > See comment 286 I had the 'When Thunderbird starts:' set to 'Keep my Chat Accounts offline', and I have now un-ticked all boxes. I'll post again if it makes any difference.
(In reply to Charles from comment #290) > Well, take a look at all of the comments in this bug. Do you really expect > volunteers to wade through the morass of comments, often rude and demanding > whining about the bug not being fixed? > > As non developers, one way we can help is to try to cut through this morass > for the devs actually willing to do the coding. That is all Tamas meant. > All valid points, but the bug is 14 years old, so no wonder it collected a lot of (often misleading) posts. Also, it is in top-10 overall by votes, and top-5 in Core, so one would expect it to be high on the priority list. It is not critical of course, and perhaps it affects only 1000 users, but these are the heaviest users, I bet. So let's hope this bug will be properly fixed before reaching the retirement age :-)
(In reply to Tamas Hubai (:htamas) from comment #283) : > === Can StartupMaster's functionality be added into Mozilla core? === > > Maybe. I still consider the solution with cross-thread synchronization > mentioned above to be cleaner. Tamas, excellent expert summary. I agree the cross-thread sync solution is cleaner, but more difficult to test and verify. It is also riskier IMO because of the usual difficulty level when dealing with thread safety. However, incorporating what your StartupMaster code does into TB at the point where StartupMaster would be invoked would be a quick, reasonable to solve this for most in the short term. It would also lessen the security issue if someone tried to spoof StartupMaster (possibly pointing to an unofficial site claiming to be a source for this add-on). Fixing this annoying bug also makes the affected Mozilla products appear more professional.
(In reply to Tim Johnson from comment #299) > Fixing this annoying bug also makes the affected Mozilla products appear > more professional. Note also that, although StartupMaster workaround handles the problem with FF in my case, it's still a crutch, not a solution. It forces me to unlock security device at once, thus defeating the very essence of securing it with password. Although it's not that dire a security issue, it's still wrong. Security device should be open when required, using single window requesting master password.
(In reply to Konstantin Boyandin from comment #300) > Note also that, although StartupMaster workaround handles the problem with > FF in my case, it's still a crutch, not a solution. +1 > It forces me to unlock security device at once, thus defeating the very > essence of securing it with password. Although it's not that dire a security > issue, it's still wrong. Security device should be open when required, using > single window requesting master password. The Software Security Device should also be equipped with an auto-locking time out. As of now, once the master password has been entered once, every password is usable by any component for any reason. Presumably, add-ons cannot directly query for cleartext passwords, but it's possibly they could fake a challenge to the core which would dutifully produce the requisite password. If an auto-lock timeout were to be added, the technique behind StartupMaster (namely, that it runs during the single-threaded startup of tb/ff and therefore avoids any threading issues) would become obsolete, since the Software Security Device could, at any time, be locked and require re-entry of the master password.
(In reply to Konstantin Boyandin from comment #300) > Note also that, although StartupMaster workaround handles the problem with > FF in my case, it's still a crutch, not a solution. > > It forces me to unlock security device at once, thus defeating the very > essence of securing it with password. Although it's not that dire a security > issue, it's still wrong. Security device should be open when required, using > single window requesting master password. I have no idea what you are talking about. In fact it appears you say one thing, then the opposite. Maybe it is a language problem. But I see no problem with how Startup Master works, and it certainly does not affect security one way or another.
(In reply to Christopher Schultz from comment #301) > (In reply to Konstantin Boyandin from comment #300) >> It [StartupMaster] forces me to unlock security device at once, thus defeating the very >> essence of securing it with password. Although it's not that dire a security >> issue, it's still wrong. Security device should be open when required, using >> single window requesting master password. > > The Software Security Device should also be equipped with an auto-locking > time out. As of now, once the master password has been entered once, every > password is usable by any component for any reason. Presumably, add-ons > cannot directly query for cleartext passwords, but it's possibly they could > fake a challenge to the core which would dutifully produce the requisite > password. > > If an auto-lock timeout were to be added, the technique behind StartupMaster > (namely, that it runs during the single-threaded startup of tb/ff and > therefore avoids any threading issues) would become obsolete, since the > Software Security Device could, at any time, be locked and require re-entry > of the master password. Interesting idea for enhancing the security of TB, but this has nothing to do with this bug. Have you opened a new bug / feature request? Will be interested to see what comes of it.
(In reply to Charles from comment #303) > (In reply to Christopher Schultz from comment #301) > > (In reply to Konstantin Boyandin from comment #300) > >> It [StartupMaster] forces me to unlock security device at once, thus defeating the very > >> essence of securing it with password. Although it's not that dire a security > >> issue, it's still wrong. Security device should be open when required, using > >> single window requesting master password. > > > > The Software Security Device should also be equipped with an auto-locking > > time out. As of now, once the master password has been entered once, every > > password is usable by any component for any reason. Presumably, add-ons > > cannot directly query for cleartext passwords, but it's possibly they could > > fake a challenge to the core which would dutifully produce the requisite > > password. > > > > If an auto-lock timeout were to be added, the technique behind StartupMaster > > (namely, that it runs during the single-threaded startup of tb/ff and > > therefore avoids any threading issues) would become obsolete, since the > > Software Security Device could, at any time, be locked and require re-entry > > of the master password. > > Interesting idea for enhancing the security of TB, but this has nothing to > do with this bug. > > Have you opened a new bug / feature request? Will be interested to see what > comes of it. Logging in and out of the security device is already implemented, but I think it only works when you enable FIPS. Go to Tools -> Options -> Advanced -> Certificates -> Security Devices. An auto logout after a a specified time sounds like a plan though.
(In reply to Charles from comment #302) > (In reply to Konstantin Boyandin from comment #300) > > Note also that, although StartupMaster workaround handles the problem with > > FF in my case, it's still a crutch, not a solution. > > > > It forces me to unlock security device at once, thus defeating the very > > essence of securing it with password. Although it's not that dire a security > > issue, it's still wrong. Security device should be open when required, using > > single window requesting master password. > > I have no idea what you are talking about. In fact it appears you say one > thing, then the opposite. Maybe it is a language problem. > > But I see no problem with how Startup Master works, and it certainly does > not affect security one way or another. StartupMaster forces to unlock Software Security Device immediately, to prevent affected Mozilla products to suffer from this (design?) bug. Mandatory unlocking security device and removing password protection from it is technically the same from security-related viewpoint. If you wish further discussion of this, language problems and other personal/philosophical aspects, you're more than welcome to do that in private. Thank you.
(In reply to Konstantin Boyandin from comment #305) > (In reply to Charles from comment #302) >> I have no idea what you are talking about. In fact it appears you say one >> thing, then the opposite. Maybe it is a language problem. >> >> But I see no problem with how Startup Master works, and it certainly does >> not affect security one way or another. > StartupMaster forces to unlock Software Security Device immediately, to > prevent affected Mozilla products to suffer from this (design?) bug. > > Mandatory unlocking security device and removing password protection from it > is technically the same from security-related viewpoint. If you wish further > discussion of this, language problems and other personal/philosophical > aspects, you're more than welcome to do that in private. Thank you. No need. StartupMaster doesn't do anything that the Master Password itself doesn't do, so your 'complaint' is meaningless. So, again, it doesn't add or subtract from the existing security offered by the Master Password function.
(In reply to Charles from comment #306) > (In reply to Konstantin Boyandin from comment #305) > > (In reply to Charles from comment #302) > >> I have no idea what you are talking about. In fact it appears you say one > >> thing, then the opposite. Maybe it is a language problem. > >> > >> But I see no problem with how Startup Master works, and it certainly does > >> not affect security one way or another. > > > StartupMaster forces to unlock Software Security Device immediately, to > > prevent affected Mozilla products to suffer from this (design?) bug. > > > > Mandatory unlocking security device and removing password protection from it > > is technically the same from security-related viewpoint. If you wish further > > discussion of this, language problems and other personal/philosophical > > aspects, you're more than welcome to do that in private. Thank you. > > No need. StartupMaster doesn't do anything that the Master Password itself > doesn't do, so your 'complaint' is meaningless. > > So, again, it doesn't add or subtract from the existing security offered by > the Master Password function. First, this is neither complaint, nor 'complaint'. This is just a statement. Whatever emotions you see in my words, that's just your imagination. Second, in *none* of my comments I expressed concern that StartupMaster can do something about master password. That's purely your imagination, so please do me a favour and stop assigning that thought to me. Once again. StartupMaster forces to unlock security device at once, thus nullifying the very idea of protecting security device with password. As I said, it's not too dire a security concern, but the fact that FF won't ask the master password under certain circumstances *does* make it less secure. Thanks for your time.
(In reply to Konstantin Boyandin from comment #307) > (In reply to Charles from comment #306) >> No need. StartupMaster doesn't do anything that the Master Password itself >> doesn't do, so your 'complaint' is meaningless. >> >> So, again, it doesn't add or subtract from the existing security offered by >> the Master Password function. > First, this is neither complaint, nor 'complaint'. This is just a statement. > Whatever emotions you see in my words, that's just your imagination. I quoted the word 'complaint' because it seemed a complaint was totally misplaced. > Second, in *none* of my comments I expressed concern that StartupMaster can > do something about master password. That's purely your imagination, so > please do me a favour and stop assigning that thought to me. Well, I didn't say anything about StartupMaster 'doing something' about Master Password, I said it doesn't do anything that the Master Password function itself doesn't do. Once again - StartupMaster doesn't change anything in regard to the way the Master Password function works, so please do us all a favor and stop suggesting that it does. If you have a complaint about the way the Master Password function works, then please go file a new bug and stop muddying the waters here. > Once again. StartupMaster forces to unlock security device at once, thus > nullifying the very idea of protecting security device with password. As I > said, it's not too dire a security concern, but the fact that FF won't ask > the master password under certain circumstances *does* make it less secure. Ok, well, reading between the lines, it sounds like you may be saying that installing StartupMaster forces a prompt for the Master Password even when one isn't being used? That would indeed be a bug, but it would be a bug in the StartupMaster Addon, no?
(In reply to Charles from comment #308) > (In reply to Konstantin Boyandin from comment #307) > > (In reply to Charles from comment #306) > >> No need. StartupMaster doesn't do anything that the Master Password itself > >> doesn't do, so your 'complaint' is meaningless. > >> > >> So, again, it doesn't add or subtract from the existing security offered by > >> the Master Password function. > > > First, this is neither complaint, nor 'complaint'. This is just a statement. > > Whatever emotions you see in my words, that's just your imagination. > > I quoted the word 'complaint' because it seemed a complaint was totally > misplaced. > > > Second, in *none* of my comments I expressed concern that StartupMaster can > > do something about master password. That's purely your imagination, so > > please do me a favour and stop assigning that thought to me. > > Well, I didn't say anything about StartupMaster 'doing something' about > Master Password, I said it doesn't do anything that the Master Password > function itself doesn't do. > > Once again - StartupMaster doesn't change anything in regard to the way the > Master Password function works, so please do us all a favor and stop > suggesting that it does. Yes it does, in the sense that under some situations (especially in FF, for example as long as no open tab requires pre-filling credentials), the Master Password is not immediately required at startup. Until it is needed, there is no prompt for it and thus, the password database stays encrypted. If I understand correctly, the complaint being made is that with the add-on, the Master Password is unconditionally requested at the beginning of the session, thus putting some kind of key material in memory for further usage even if it is not immediately needed. And according to him, this is somewhat less secure than the situation where no key material is requested until being effectively needed. > > If you have a complaint about the way the Master Password function works, > then please go file a new bug and stop muddying the waters here. > > > Once again. StartupMaster forces to unlock security device at once, thus > > nullifying the very idea of protecting security device with password. As I > > said, it's not too dire a security concern, but the fact that FF won't ask > > the master password under certain circumstances *does* make it less secure. > > Ok, well, reading between the lines, it sounds like you may be saying that > installing StartupMaster forces a prompt for the Master Password even when > one isn't being used? That would indeed be a bug, but it would be a bug in > the StartupMaster Addon, no? Nope that's not what he was saying. Some communication problems and aggravated feelings have led you to a "qui pro quo": "the master password being set up but not yet required" is a different thing than "master password isn't used at all (not set)". He is speaking of the first while you think of the latter.
Could you PLEASE take this discussion elsewhere instead of bloating this ticket with offtopic discussions about third party tools and whatnot, effectively making it harder to read this ticket and spamming everyones inboxes with stuff unrelated to this (very specific) ticket we subscribed to? PLEASE. Thank you
(In reply to Zertrin from comment #309) > (In reply to Charles from comment #308) >> Ok, well, reading between the lines, it sounds like you may be saying that >> installing StartupMaster forces a prompt for the Master Password even when >> one isn't being used? That would indeed be a bug, but it would be a bug in >> the StartupMaster Addon, no? > Nope that's not what he was saying. Some communication problems and > aggravated feelings have led you to a "qui pro quo": "the master password > being set up but not yet required" is a different thing than "master > password isn't used at all (not set)". He is speaking of the first while you > think of the latter. Ah, ok, well that clarifies things, thanks very much. This is what I meant when I said maybe it is a language problem. My apologies to you, Konstantin, I now understand and see that your complaint is valid. I don't even use StartupMaster in Firefox (I have never had a need for it since I never store passwords or anything in the browser for security reason - I use a password manager), so I was thinking more in terms of Thunderbird. Tamas: would it be possible to address this in StartupMaster (ie, and option to only kick-in the first time the Master Password is called)? I'm thinking no, because of the way it works, but you'd obviously know better... Thanks again for clarifying things Zertrin...
(In reply to kissaki from comment #310) > Could you PLEASE take this discussion elsewhere instead of bloating this > ticket with offtopic discussions about third party tools and whatnot, > effectively making it harder to read this ticket and spamming everyones > inboxes with stuff unrelated to this (very specific) ticket we subscribed to? > > PLEASE. Thank you Actually, I think this was very productive, and since StartupMaster is actually a candidate for SOLVING this long standing bug, I think discussion about it in this context is highly relevant to this bug. Sorry if you disagree.
(In reply to Charles from comment #311) > (In reply to Zertrin from comment #309) > > (In reply to Charles from comment #308) > >> Ok, well, reading between the lines, it sounds like you may be saying that > >> installing StartupMaster forces a prompt for the Master Password even when > >> one isn't being used? That would indeed be a bug, but it would be a bug in > >> the StartupMaster Addon, no? > > > Nope that's not what he was saying. Some communication problems and > > aggravated feelings have led you to a "qui pro quo": "the master password > > being set up but not yet required" is a different thing than "master > > password isn't used at all (not set)". He is speaking of the first while you > > think of the latter. > > Ah, ok, well that clarifies things, thanks very much. This is what I meant > when I said maybe it is a language problem. > > My apologies to you, Konstantin, I now understand and see that your > complaint is valid. I don't even use StartupMaster in Firefox (I have never > had a need for it since I never store passwords or anything in the browser > for security reason - I use a password manager), so I was thinking more in > terms of Thunderbird. [...] No problem, Charles, I am glad it has been cleared, thanks to Zertrin. And of course, I would post StartupMaster-related issues to its own bugs tracker. When I disable synchronization to Mozilla account *and* Xmarks auto-sync, this bug doesn't happen. Otherwise, I see 2 or more pop-ups waiting for master password. If I don't enter anything for considerable time (at least 5 minutes), chances are FF would lock up GUI (Ubuntu 16.04 64-bit in use) until X server is restarted. I use FF build downloaded from Mozilla site.
(In reply to Charles from comment #312) > > Actually, I think this was very productive, and since StartupMaster is > actually a candidate for SOLVING this long standing bug, I think discussion > about it in this context is highly relevant to this bug. > > Sorry if you disagree. No addon EVER will be a solution to a bug in the CORE system of mozilla. Even if the discussion may have been productive, it is far more important that this bug is solved inside the core components. Now please stop discussing offtopic things here, as stated already by kissaki in comment #310. Thanks a lot, but this bug seems to be becoming the most annoying (and also oldest) bug in mozilla firefox and thunderbird. Isn't there a bug bounty for the oldest bug?
(In reply to Dirk Wissmann from comment #314) > (In reply to Charles from comment #312) >> Actually, I think this was very productive, and since StartupMaster is >> actually a candidate for SOLVING this long standing bug, I think discussion >> about it in this context is highly relevant to this bug. >> >> Sorry if you disagree. > No addon EVER will be a solution to a bug in the CORE system of mozilla. In the long term I agree - which is why, in my comment 289, I mentioned that I had opened bug 1313658 specifically requesting that the functionality of StartupMaster Addon be incorporated INTO THE CORE CODE. That is what I meant when I mentioned that this conversation had been productive. It also clarified how the problem (and behavior of StartupMaster) differs in Firefox as opposed to Thunderbird.
TEST CASE - Firefox Core Code I have managed to recreate the issue without any addons installed and I set up a new profile. In this profile I amended a few settings - such as History is removed when you shut down Firefox and also I added three tabs to be opened when Firefox starts, namely https://www.google.com/ncr|https://www.yahoo.com|https://www.google.co.uk I saved against the Google and Yahoo sites a username and password (Not passwords that worked as it was not needed) I also set a Master Password and enabled with a new account a Firefox Sync All you need to do is Press the sign in button for one of the tabs as soon as Firefox has started and you will be prompted for a master password. Now wait around 10 seconds and you will then be prompted again for a master password (as you now have two prompts) Case proven.
Please note that the Test Case Needs NO ADDONS - it works with just the Firefox code, history removed at the end of a session, All Cookies lost after a session ends, three default webpages set with remembered passwords, master password set, and Firefox Sync enabled but not to remember history or cookies...
bug 643265 is a duplicate, not a dependent.
I believe the bug is related to authentication method (oauth2) with mutliple Gmail accounts. I've been able to reproduce the problem in Thunderbird 52.0 with 3 email accounts (IMAP). 2 of them are from Gmail with default settings. To avoid multiple master password prompts I switched IMAP server authentication from "oauth2" to "normal password" (look at "Server Settings" > "Security Settings" > "Authentication method").
Piotr, please note in the comments, that not only thunderbird, but also firefox is affected by this bug. Firefox has nothing to do with mails or mail accounts, so no chance to switch something from "oauth2" to "normal". It's really disappointing, that this really annoying bug isn't fixed for 15 years now. Even if it is a race condition, as several comments indicate, there should be a solution after this long time. I think in firefox, the problem can be reproduced by having a master password applied, firefox sync is active, and you have a starting page where a username/password combination must be entered, which is already in the password container. At least, with this combination, I always get at least two master password dialogues.
You're right Dirk, my workaround won't help Firefox user. I have never encounter this bug with my browser but I will try to reproduce it and see what's wrong. For Thunderbird, there is something else to try. Instead of switching from "Oauth2" authentication to "normal" with Gmail account, just uncheck "Check for new messages at startup".
(In reply to Piotr from comment #326) > I believe the bug is related to authentication method (oauth2) with mutliple > Gmail accounts. > Check out bug 1176399, it has been fixed a couple of days ago for 55
It is quite surprising that this bug needed 15 years to get fixed. I would say that there is a simple rule here to follow. Any piece of code which wants to have private information should queue behind one entity (i.e. piece of code) which manages access to private information and NOT jump directly on the user. Really, 15 years to think about this???? Anyway, it is nice to hear that in version 55 there seems to be a fix. However, the current official version is 52(!!!) and even the early bird version which I found was only is only 54(!!!). Would it be possible to speed up this fix a bit? Currently, I am getting 6 requests for Thunderbird at start up. Ok, I have to answer the prompt only for the first and cancel all the others but it is still more than annoying. Using Thunderbird 52 on Windows 10x64 with Google Provider and SOGO. And no! It is not a problem of multiple accounts. I am only using one Google account but access email and multiple calendars with it.
(In reply to Klaus Fischer from comment #330) > Anyway, it is nice to hear that in version 55 there seems to be a fix. > However, the current official version is 52(!!!) and even the early bird > version which I found was only is only 54(!!!). Read comment #329 again. This bug is not fixed, but a bug in Thunderbird which triggered this bug is. As has been said in several places (probably including this bug, though I didn't read through all 300 comments to find out) there are large architectural problems that make this bug really difficult to solve. It isn't a matter of "just doing it". Not only that but Master Password in general does not actually provide a whole lot of security. I believe if you dig through the dev-platform archives you can find an email thread talking about axing Master Password entirely because of security problems.
Hi Alex, thanks for your comment. I do agree that TB unfortunately has sever architectural problems and, I am sorry to say, because some simple design principles are not taken into account as it is obvious from the problems with this bug. And yes, I do agree that a master password is a security problem on its own. However, whoever would use the password manager of a browser for anything else than what is usually referred to as trivial passwords where the worst things that might happen is that forums like for example bugzilla or people who happen to be listed in the TB address book are spammed by stupid messages is at least in my opinion out of his or her mind. And for this, that we talk about trivial security here where there is no need for anything really complicated because it is only meant for stopping dummys from doing stupid things, convenience would be of major importance.
Could someone with +editbugs double-check and set the following flags please? Depends on: 1271851 See Also: 1271852 Duplicates: 550304, 833272, 1261021, 1267005
Depends on: 1271851
See Also: → 1271852
See Also: → 550304, 1261021, 1267005, 1176399
Hello, By the way, it could be great not to display at all the prompt when you're in fullscreen mode like watching a serie on netflix. You're quietly in your sofa and hop, the prompt appears. A bit annoying.
Attached image screenshot —
my God , the mistake 15 years !
Sorry for being a bit off topic: (In reply to AJ Jordan [:strugee] from comment #331) > Not only that but Master Password in > general does not actually provide a whole lot of security. I believe if you > dig through the dev-platform archives you can find an email thread talking > about axing Master Password entirely because of security problems. I have tried to find facts backing this claim but only found lots of political agenda and plenty of ego boosted comments about "I like to do it this way so it must be the way". (mostly around bug 309807) I do not have any evidence that by using a secure password for master password would make it possible for the attacker to read the passwords from the disk storage, any encryption flaws, or any related security flaws. I'm eager to see them. But I am sure that Master Password actually offers plenty of security against plain-text stored passwords, same password for everything, and post-it notes of passwords on the monitor, at least. Actually keepass and other advices just follow the same path (encrypting password store with a master password), so it would help to actually name the specific security problems instead of hinting them. (I'm not aware any well-integrated password storage which offers known and proven security and no "cloud", and survive the recent extension eredication movement. Oh, and I don't use kde or gnome and I wouldn't like to use their [to me] inflexible methods.) I do not consider user stupidity a "master password security problem", like using "123" or "" for password, or leaving the browser open and alone (though I would really appreciate Master Password Timeout implemented, or the killed-off extension rewritten for Nightly but it seems nobody on this planet is able to do it :-/). I am also annoyed by people suggesting "cloud based solution" (cloud is, as you know, "someone else's computer") while not accepting the fact that significant amount of people want to be in charge of their own data, especially for those people administering hundreds or thousands of servers. Technically this bug is not about killing off PM, and if there's such a bug I'd prefer to know about it, and avoid discussing it here. As a sidenote I haven't had this problem (multiple password prompts) for years (and it doesn't mean it's fixed, it just worksforme).
(In reply to Peter Gervai from comment #336) I have to agree with the comments above. It is a scandal that Mozilla have left this bug on the backburner for 15 years! The "current plan" is to decouple password manager to allow them to possibly fix the issue. Given that their appears to be a race condition in the code, and or no check to see if there is an active message waiting for a reply from the user, it shouldn't be beyond the development and support teams ability to fix this issue. A test case that works without any addons - was supplied to this case and nothing has been done with it. My "workaround" with Firefox is to open the browser with no home page - therefore only one prompt appears asking for a password. Once entered, I then can browse without having multiple prompts.
(In reply to Tamas Hubai [:htamas] from comment #338) > Hello. This is an advance warning that StartupMaster is no longer compatible > with Firefox 57, to be released in two weeks, due to discontinued API access > to master passwords. There is a more detailed FAQ at > http://htamas.ces.hu/startupmaster/webext.html. > > On a side note, I got into a disagreement with Justin Dolske in bug 1361838 > on whether upgrading to Firefox 57 will inherently solve the multiple > password prompts issue. While I seriously doubt it, I don't have a specific > counterexample at hand, so if you have the time to compile a current list of > steps to reproduce, preferably using a clean profile, please contribute it. > > Lastly, if you are from Mozilla and happen to know where the discussion on > the future of the built-in password manager takes place, I would be grateful > to learn about it. Please see test case in comment 316 that works with a clean profile
Ok, thanks, I can verify the STR with current nightly (Gecko 58). Actually it is enough to open a single page with a saved password and restart the browser, once you have enabled sync.
Has anything changed around this issue? I did't see a second master password prompt today--the second time I let Firefox sit for over ten minutes. I started Nightly with the same set of saved tabs which have caused multiple master password prompts for months.
(In reply to B.J. Herbison from comment #341) > Has anything changed around this issue? I did't see a second master password > prompt today--the second time I let Firefox sit for over ten minutes. > > I started Nightly with the same set of saved tabs which have caused multiple > master password prompts for months. Bug 1382937 was fixed, which should stop Sync showing a second prompt when one is already open - however, it doesn't fix other scenarios where this might happen.
Nothing changed, the bug is still there. It is reproducible with the following steps: Start Firefox with a new (clean) profile. Set a master password. Enable FIPS. Restart Firefox. The result: https://imgur.com/a/41al3 Version: 57.0.1 (64 bit) Firefox for openSUSE Leap (openSUSE 42.3)
Version 58.0 (64-bit) Windows 10 & mac, the bug is still there. Two tabs requiring sign-in left open when I quit => 2 master password dialogs when I start again. I can fill out one and dismiss the other without problems, but it's the most annoying thing in my life at that exact moment. BTW Not a duplicate of 1430920, different behaviour.
Seems that the number of installed emailaccounts masterpasswort prompts are opened at start.
At least for me the issue seems to have gone away in Thunderbird-52.9.0 (52.8.0 had it). Not sure if a temporary fluke or if some unrelated change made the bug go away.
It is fixed for me too on 60. 0b10. And the addon that had fixed it is gone, so the core must be fixed now.
Not fixed for me ! Running Thunderbird 52.9.1 on Win 7 OS and still getting multiple password requests if I disable the StartupMaster add-on I've been using as a work around for years. I would have thought if any release that had fixed such a long standing issue would have made a big thing of it. I personally have seen no mention of multiple password requests being fixed in the change logs of any recent version.
It went away (I think in 60.?) and it's back in 61.0.1
(In reply to stib from comment #351) > It went away (I think in 60.?) and it's back in 61.0.1 It is there in 60 too, with FIPS enabled, and disabled too.
Still a BUG!! Very annoying! What's the fix or work-around? But only happens on some profiles, i think profiles i've had for eons, does not seem to happen on newer profiles, i'm not going to delete my profiles to "fix" this, this may be a "red herring" though.
(In reply to Cor'e from comment #353) > What's the fix or work-around? No fix. Workarounds I use routinely: 1. Copy/paste password (from software password safe) multiple times :( 2. Enter password once, CANCEL remaining requests Entering the password correctly a single time seems to work even if you dismiss the remaining requests with the ESC key or pressing the CANCEL button
Yeahhhh ! Great to see it solved in TB 60.2.1 :))))
See Also: → 1514118

(In reply to Sisim Biva from comment #355)

Yeahhhh ! Great to see it solved in TB 60.2.1 :))))

Is there any official statement? What change did fix this?
I'm still using StartupMaster on Thunderbird which prevents this problem along with some other advantages - but I ran into trouble with Firefox...
I was using FF56 for almost 2 years now, ignoring the "deprecated" warnings - but there seems to be no solution for bug #1548973 for older versions, which disables some other add-ons.
Any progress in solving this one for Firefox?

No, it's not solved. I see the same problem again in 60.8.0

It's the truth. Bug can not remove 10 years. Terribly annoying behavior. This bug interferes with the efficiency of the computer, when you quickly type a long password and half of it is in the second window. Well that at least three Windows not coming up ! Probably transfer about 500 users on CHROME.

An update to Thunderbird 68 surprised me with a slew of incompatible extensions, including Startup Master that I used as a workaround for this bug.

I am pleased to report that the the native master password dialog is only appearing once for me as expected.

This may finally be resolved.

Same issue: my landing page request several master password. screenshot: https://photos.app.goo.gl/HpES1YeXYqtxLiDn9

Bug 1587927 should help reduce this for password manager triggered cases.

Matt, is this multiple MP prompt still an issue? We believe we fixed most/all the issues in Thunderbird that came from mail code, see my last comment on the issue in bug 584014 comment #71.

Flags: needinfo?(MattN+bmo)

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Keywords: regression

on Windows 7 x64 en-US firefox 71.0 this does seem to be resolved, I get only one Master Password Prompt

(In reply to Jorg K (GMT+1) (PTO to 5th Jan 2020, sporadically reading bugmail) from comment #365)

Matt, is this multiple MP prompt still an issue? We believe we fixed most/all the issues in Thunderbird that came from mail code, see my last comment on the issue in bug 584014 comment #71.

I think this bug is about preventing the root case in PSM code that opens the dialog whereas Firefox and TB have worked around the issue by adding its own logic. I think it would still be good to have PSM code focus/re-use an existing MP dialog when one is already opened.

Flags: needinfo?(MattN+bmo)
Keywords: regression

FWIW, Thunderbird 68 still has problems with multiple MP dialogs (for me as well as other users apparently), so if there's a central component that could fix it in a single shot, that would probably be a very good investment in product quality.

I also think it would be very reasonable to solve it the way that's suggested in this bug report. I'm actually thinking in terms of a singleton, but of course I'm not at all familiar with your codebase. Good luck.

Still an issue here (thunderbird 68.2.2 (64-bit) on kubuntu linux 19.10). Multiple IMAP accounts and multiple SMTP servers.

  • Thunderbird asks for the password at least twice on startup.
  • If one is not fast at entering the passwords, thunderbird floods the display with password windows.
  • Startup Master that was working around the issue does not work anymore, so no workaround currently exists.

This issue has been ongoing for a long long time eh ☹️ Startup Master used to fix the issue but alas that no longer works with the latest Thunderbird and Firefox builds ☹️

To get around the issue of multiple prompts in Thunderbird, turn off ”check mail on startup” for all accounts except your primary one. This should present you with just one prompt to enter your master password. The other accounts will all have there checking deferred if the other option ”check mail every n minutes” is enabled.

If you don't respond to this prompt before the ”check mail every n minutes” option gets triggered then you'll get the multiple prompts again. In this case perhaps increase the ”n” minutes to allow for the distracted focus or don't get distracted 😉

For Firefox, as far as I can tell, the issue only occurs, if you have the ”open windows/tabs from last time” option enabled or are restoring from a saved session, and, there's more than one window opening. Each window containing at least one tab that triggers a login event then triggers the ”Master Password” prompt. So if your restored session has say 5 windows and 3 of those windows have tabs that request some sort of login details then you get 3 prompts.

What needs sorting is for PSM ”Password Session Manager” to keep track of the dialog/window used to request the ”Master Password” and if it's already been created then to trigger the focus on it again instead of creating another one.
In the older days of UI/UX this would've been a modal dialog/window that would block the parent window from receiving input until the modal had been confirmed or cancelled. However most new UX standards seem to recommend not ”blocking” the UI and instead use notifications or refocusing attention. Perhaps this isn't as easy as I think because the issue is with PSM which might be running as a separate process?

For Firefox, as far as I can tell, the issue only occurs, if you have the ”open windows/tabs from last time” option enabled or are restoring from a saved session,

Can you specify which version and which build and on which Operating System ?
this has stopped being an issue since the last 3 builds for me on Windows

issue of multiple prompts in Thunderbird, turn off ”check mail on startup”
Sorry I don't use that so can't comment

I see two dialogs on startup, using thunderbird-68.3.0-3.el6.centos.x86_64 on CentOS Linux 6.10. [wow, "Opened 17 years ago"]

I haven't experienced symptoms in Thunderbird since installing the Startup Master extension some years ago. Much to my delight, symptoms did not return after Startup Master became incompatible.

I have 6 email accounts, two of which are Gmail using OAuth, as well as several calendars from various sources, including Google, as well as ICS feeds and CalDAV. All the email accounts have 'Check for new messages at startup' enabled.

Information for package MozillaThunderbird:

Repository : Mozilla based projects (openSUSE_Leap_15.1)
Name : MozillaThunderbird
Version : 68.3.1-lp151.2.1
Arch : x86_64
Vendor : obs://build.opensuse.org/mozilla
Installed Size : 174.5 MiB
Installed : Yes
Status : up-to-date
Source package : MozillaThunderbird-68.3.1-lp151.2.1.src

(In reply to Link @ QPG from comment #374)

I haven't experienced symptoms in Thunderbird since installing the Startup Master extension some years ago. Much to my delight, symptoms did not return after Startup Master became incompatible.

I have 6 email accounts, two of which are Gmail using OAuth, as well as several calendars from various sources, including Google, as well as ICS feeds and CalDAV. All the email accounts have 'Check for new messages at startup' enabled.

Same here. Two Gmail IMAP accounts with 'Check for new messages at startup' enabled and a couple of Google calendars via CalDAV. Only one master password dialog on startup. Thunderbird 68.3.1 on Windows.

THose of you who state only a single master password dialog: Can you test if you get multiple ones if you leave TB with that initial dialog open/unanswered for a while? I expect that you will get multiple dialogs if you wait until TB starts looking for new messages according to your configured schedules. At least that's what happens to me.

leave TB with that initial dialog open/unanswered for a while

Filed as bug 1606711 for Thunderbird.

@Julz and others. I currently have no account at all with "Check email on startup" ticked, all my accounts have checking intervals in the 5-10 min range. Still, with this I get 3 master password dialogs at startup, which become even more if I wait to enter my password in them.

After this test the matter is even more nasty. Why is thunderbird asking me the password 3 times if it is not even checking my email accounts?

Is there a way to know what thunderbird is trying to access saved passwords for?

Please comment in bug 1606711 for Thunderbird.

Inspired by comments saying that some users were not experiencing the issue, I have decided to restart from an empty profile. This has been a quite painful experience, re-adding and reconfiguring extensions, adding and configuring multiple email accounts, each with its imap and smtp server, configuring some local email stores, re-adding address books took me hours. However, the issue is now gone. So I would say that the issue is caused by incorrect profile information, which in turn likely comes from incorrect interpretation or migration of past configuration formats.

Incidentally, in the experience I have learnt the following items:

  • trying to reuse past address books mab files with the addressbooksynchronizer extension is error prone. It gave me errors in importing one of the mab files. I had to export it as CSV and re-import the addresses. In this way all the mailing lists are lost, and I had to export them individually as CSV files, which was a real pain. I really think that TB should learn to export/import its address books in some JSON or YAML format preserving the mailing lists.

  • There is no easy way to export/import an email account configuration. TB should learn to export/import account configuration in some structured text format (JSON or YAML).

  • Creating new email accounts from scratch, they get set up with the "Keep messages in all folders for this account on this computer" and "Syncronize all messages locally regardless of age". IMHO this is looking for trouble. Downloading many GBs of messages from each account quicly filled my disk blocking my machine and risking data loss. I think that TB should default to only sync locally /recent/ messages on IMAP accounts. The issue is made worse by the fact that when you change the setup TB does not reclaim the space.

This is all off-topic in this bug which is about fixing a multiple password issue at Mozilla Core level. However, I have the following remarks:

  • Sadly TB is lacking a "refresh profile", see bug 584014 comment #85 and below. One experiment one could to for a refresh would be to remove all prefs from prefs.js other than the ones listed below. OF COURSE after making a backup. I filed bug 1608031 for "refresh profile".
  • Did you look at https://addons.thunderbird.net/en-GB/thunderbird/addon/importexporttools-ng/ ? I don't know whether it can handle address books.
  • The hack way to maintain account setup is to copy the account part of the old prefs.js to the new prefs.js. That would be the mail.account.*, mail.identity.*, mail.server.* and mail.smtpserver.* prefs. There is also messenger.account.* for chat accounts. Warning: Just a suggestion, I've never tried it myself.
  • I believe that copying the ldap_2.* prefs and copying the .mab files would also copy over the address book information.

(In reply to Sergio Callegari from comment #380)

Inspired by comments saying that some users were not experiencing the issue, I have decided to restart from an empty profile. This has been a quite painful experience, re-adding and reconfiguring extensions, adding and configuring multiple email accounts, each with its imap and smtp server, configuring some local email stores, re-adding address books took me hours. However, the issue is now gone. So I would say that the issue is caused by incorrect profile information, which in turn likely comes from incorrect interpretation or migration of past configuration formats.

Do you have a copy of the old profile? Maybe you could diff them and come up with interesting differences, as clues to what may be causing the multiple password prompts as well as bugs in the profile upgrades, that need to be fixed?

@Sergio Callegari, I know I'm continuing off-topic a bit, but there are other bugs for converting Thunderbird's data to a newer and more performant format, like bug 11050 (which has been open 21 years...) or bug 361807. Thunderbird just doesn't get as much love as Firefox, which has been entirely converted. I'd love to see json for configuration and sqlite/localStorage for everything else, too.

I know the feeling, I'm still rocking FF and TB profiles that have been continually migrated from Netscape 6, despite many extensions and customizations over the decades; never refreshed but occasionally manually cleaned up. Firefox has dealt pretty much without issue. It sounds like it's time to just bite the bullet and redo my TB from scratch to eliminate the need for StartupMaster. The steady attrition of people doing so might be why this bug has become a lot less active over the years.

I've spent some time investigating the code and what's happening. All decryption goes through the UI thread, which then brings up the prompt. The event loop spins while it's showing, so other activity is called, decides it needs a login, will call decrypt, which will bring up another prompt. We cannot block in those scenarios, as it would prevent being able to unwind the lower place in the call stack. We also cannot simply return a failure to that additional activity, as that will cause it to run into a failure scenario (prompt for server password).

The only "real" solution I see at the code level:

  • we must change the login decryption to be async
  • if we're in the middle of decryption, while another request to decrypt is received, it must return "would block"
  • all code that attempts to decrypt a login needs to be prepared to get a "would block" answer, and set some timeout to try again later (or wait for some new broadcasted event that we'd define)

Kai, I believe you're got it conceptually. It seems that the decrypt function should have been implemented as a singleton. Then all subsequent callers would be blocked until the first thread which called either got a correct password, or failed. I think I've seen that suggestion in other comments over the years related to this issue.

See Also: → 1606711

More off topic:

(In reply to kjell from comment #382)

Do you have a copy of the old profile? Maybe you could diff them and come up with interesting differences, ...

It could be that the issue is not in the preferences (prefs.js) but is due to the migration of security databases cert8.db->cert9.db and key3.db to key4.db. Obviously a new profile won't have migrated files.

Blocks: 1610390
See Also: → 1180374

Have not read the above chain ... but at least i have not open a new bug ... I could could imagine that for security reasons its not easy to reduce these multiple master password request into one request ... but each of these multiple request should at least identify the reason or the entity that request the password ... iI get 5 requests ... i don't known "what" is on the other side ... that is also a security problem ... so a title which identify the originating entity would be nice ... thanks

Thunderbird users who still see a problem when using Thunderbird 78.3.0 or 82 beta, and don't see a match to their problem in this query, please file a new bug in Thunderbird https://bugzilla.mozilla.org/enter_bug.cgi?product=Thunderbird&component=Security

Blocks: 1685877

Note: due to bug 1721084 this started to happen very often for many users again.

this = multiple master/primary password dialogs appearing

On 91.0.1 I am always getting the first password dialog duplicated (i.e. two times almost at the same time). Then I am getting further random password dialogs while working.

This is particularly annoying in linux where you use virtual desktops, because:

  • the dialogs often appear on some other desktop than the one where you use firefox because as you work you change desktops
  • when you get back to the desktop where you have firefox, you do not realize there was some password dialog open somewhere else, you try to use firefox, everything at the first instant seems to work because the password dialogs are not modal, but firefox cannot load pages and everything looks like you have a network issue.

If I could vote the single thing that would make me desire to jump to another browser, this would be it. Fortunately, I see many reasons to stay ;-)

(In reply to David Balažic from comment #389)

Note: due to bug 1721084 this started to happen very often for many users again.

this = multiple master/primary password dialogs appearing

After that bug is fixed, this still happens.

I have 91.0.2 and after start I got two password dialogs. One is blocking the other (modal). See attached screenshot.

Just want to add my two cents: On MacOS I get this in Firefox, too. The problem here is more severe, though, because Firefox will lock up itself with a password prompt in the background. This prompt in the background cannot be closed and nothing can be entered. Even if I enter the right password in the foreground password prompt the prompt in the background stays. I can only hard close firefox.

The only way I can startup firefox is:

  • Start the browser
  • Hold ESC the whole time so popping up password prompts get closed before they overlap
  • After things have settled (about 5 seconds) I manually trigger the password prompt by clicking on my firefox account menu bar button (which seems to trigger the password prompt)
  • Now only one password prompt opens, I can enter my password, all good

I've attached a video to show it what happens when I don't hold ESC and the non closable password prompt gets created in the background.

Actually it is like this fore some years like this already, currently on 98.0b7. I had multiple profile changes in between, only connected by firefox sync.

The issue keeps happening. Leaving the machine for a short time and coming back it is not unusual to find 5-6 password dialogs on screen. Similarly it is not unusual to get a password dialog opening while you are writing in another password dialog. Unfortunately is one of those little irritating things that can severely harm the impression of professional grade users get of a software and make they jump elsewhere (much more of performance differences whose appreciation is almost negligible on fast machines anyway).

Having multiple unnecessary password dialogs opening all the time is also a security issue. When there are too many, people stops giving any due attention to them and just mechanically typing it the password. I am pretty sure that making a malicious app or website showing something just barely resembling the firefox password dialog would allow some evil person to capture tons of firefox primary passwords due to the way users have starting dealing with them because of their inflation. Security people know well that an important ingredient for a successful phishing attack is to abuse something the victim will expect and not give due attention to.

Please start consider this problem not as a minor nuisance but as something that can actually actively promote phishing or compromise the secrecy of primary passwords.

If this feature cannot be made to work properly, may I suggest providing a switch in the passwords setup section letting the internal password store be disabled altogether in favor of password managers available as extensions?

(In reply to Sergio Callegari from comment #394)

The issue keeps happening. Leaving the machine for a short time and coming back it is not unusual to find 5-6 password dialogs on screen.

Hello Sergio,

Could you try to reproduce the problem with a totally new installation of Firefox, a totally new profile please, absolutely no extension and all the default settings? On which operating system are you having this problem? Do you new how to create a new profile (and be sure that you are not using your previous profile)?

I have been having this problem of multiple displays of the "Master Password" prompt for a long time until I started anew with a new Firefox installation and a new profile. I got this solution by reading this ticket some years back. And anyway starting anew with a clean slate (new install+new profile) is a good thing for the security and speed of your browsing. It takes some time afterward to tune everything again, but it will walk you through all the previous settings you had set, it will rise questions. For my case starting anew with a clean state also solved other bugs I had (some security settings I had manually set in about:config but which were not appropriate anymore, etc.).

With your totally fresh installation, if the problem persist what would be helpful would be that you coin what specific settings are producing the situation the multiple displays.

And could you then report back here whether it solved your problem or not please?

Best regards

Screenshot with two password windows...

Screenshot above (https://bugzilla.mozilla.org/attachment.cgi?id=9279421) was taken with a quite recent firefox (101.0) on an almost fresh profile (I have re-installed all the extensions that I like to have).

My extensions are:

  • Cookie autodelete
  • EzProxy Redirect Foxified
  • Facebook container
  • Feedbro
  • Firefox Multi Account container (no containers being used at the time of the incident)
  • Markdown Viewer
  • PassFF
  • Plasma Integration
  • Print Edit WE
  • Simple Google Translate
  • uBlock Origin

Behavior was quite interesting:

  1. A first password required dialog opened;
  2. While typing into it, a second one opened, stealing focus, which is why you see password dots in both dialogs, since as I was typing characters started going into the new window
  3. Filling the most recently appeared dialog is needed, if you cancel a new dialog appears.
  4. Once this dialog is filled, what you typed in the the previous one does not matter at all. You can press Sign-in with any text as the password and the first dialog goes away.

Is something producing a fake dialog here?

(In reply to Sergio Callegari from comment #398)

Screenshot above (https://bugzilla.mozilla.org/attachment.cgi?id=9279421) was taken with a quite recent firefox (101.0) on an almost fresh profile (I have re-installed all the extensions that I like to have).

My extensions are:

  • Cookie autodelete
  • EzProxy Redirect Foxified
  • Facebook container
  • Feedbro
  • Firefox Multi Account container (no containers being used at the time of the incident)
  • Markdown Viewer
  • PassFF
  • Plasma Integration
  • Print Edit WE
  • Simple Google Translate
  • uBlock Origin

Behavior was quite interesting:

  1. A first password required dialog opened;
  2. While typing into it, a second one opened, stealing focus, which is why you see password dots in both dialogs, since as I was typing characters started going into the new window
  3. Filling the most recently appeared dialog is needed, if you cancel a new dialog appears.
  4. Once this dialog is filled, what you typed in the the previous one does not matter at all. You can press Sign-in with any text as the password and the first dialog goes away.

Is something producing a fake dialog here?

Hello, I had the same issue earlier and it was fixed by deleting every setting of the GUI I use. Can you please try to setup a new user on your OS and try the same with it. If the multiple dialog isn't present, than probably your GUI's setting are the cause (especially if you upgraded your OS several times, keeping the GUI settings).

That may be the case, but interestingly Firefox is the only browser showing this behavior. From what you say, I wonder if the plasma integration add-on could be under suspicion, being the only item interacting with the rest of my OS graphical environment.

No, I'm also using the Plasma Integration add-on, and I don't faced this issue since years. I am also deleting the user settings after some OS upgrades if I see any unusual behavior. If it works well with a new user, you can try to delete first only the GTK setting of your existing user with the following command: tar -czf gtk_configuration_$(date +%D).tar.gz .gtk* .config/gtk* ; rm -rf .gtk* .config/gtk*
After the execution logout from your account and login again. If you would need those settings, you can restore them from the tar.gz file.
If it doesn't works, than you should go with the deletion of the whole user configuration:
tar -czf user_xyz_configuration_$(date +%D).tar.gz .local/ .config/ .kde4; rm -rf .local/ .kde4/ .config/

But first try it with a totally newly created OS user to make sure that this is your case too.

I am still trying to investigate the issue. I am now getting it again on a recently installed Manjaro machine. I still have not managed finding out if it depends on something on the profile or a specific extension. However I have found something that sounds a bit worrying to me:

Is one of the dialogs fake, that is a window /pretending/ to be a firefox dialog?

When I am getting multiple dialogs, one of them appears to behave differently from the others. Whatever you type in it when you press OK it goes away, no matter if you have typed the wrong password or the right one or complete nonsense. For all the other dialogs, if you enter the wrong password, then a new dialog appears prompting again.

Are others who get multiple password dialogs experiencing the same issue?

Yes, I see the same: two prompts, one of which seems happy to accept any text, the other which returns if the wrong text is entered.

I'm not sure why you guys would expect anything else to happen; you can't decrypt an already open secure store again, and the dialog box NEVER produces a message on error, it just goes away no matter what until the next attempted store access, which will normally occur immediately after it closes. So when you put the real password in, it decrypts, and then anything you type in the next one will either get an error of store already open, or perhaps wrong password, assuming it even bothers to check the result.

Well, Emily, actually I would. While I agree that "you can't decrypt an already open secure store again" I would argue that it is a bug in the first place to ask again for a password for an already decrypted secure store. Once the store is decrypted TB should be silent ...

And forgot to say, yes, if the first input is wrong, i.e. the input does not allow to decrypt the store, then of course, TB should ask back. However, with a bit of a different message, please. For example "Authentication failed: Please re-enter password" or something similar. And please add the feature to visualize the password and/or indicated whether caps lock is active. However, caps lock is not the only trap here. I don't know how many times I tricked myself because I was not aware the active keyboard layout was different from what I saw on the keys. And for whatever reason, even brand new wireless keyboards have the bad habit to eat input characters ...

@Emily Bowman

I'm not sure why you guys would expect anything else to happen
the dialog box NEVER produces a message on error, it just goes away no matter what until the next attempted store access

Indeed. I have checked that if I "cancel" the first modal dialog, then the second modal dialog does not go away if I enter a wrong password. This is somehow reassuring that the dialog is not something not part of firefox created ad hoc to capture my master password, but most likely really a second password dialog from firefox that should not appear but does.

So in some sense this is reassuring.

On some other level it is not. Suppose that one had on the system a malicious application or whatever showing a master password dialog pretending to be firefox just to capture the password. One would easily recognize it if firefox systematically repeated the password prompt in case of a wrong password. In fact the malicious application would not be able to to that, not knowing how to recognize the correct password beforehand. But now, it turns out that also firefox shows password dialogs that do not re-prompt if one enters a wrong password. So to distinguish in between the two by behavior is not possible.

For this reason IMHO it is even more important that firefox avoids producing multiple password dialogs, no matter how outdated or even broken the user profile or what extensions and add-ons he/she has installed.

As a final remark, I would add that my impression is that the second password dialog is the result of a race, because it tends to appear /immediately/ after the first one is displayed.

I managed to solve this for my case by removing the Vaultpass extension which must have also tried to check the password storage at Firefox startup causing not just the regular master password prompt popup but a second one to follow shortly after right as the extension's toolbar icon appeared (Bit of a visual give-away on which extension was the cause in my case)

I verified this by running firefox with the --safe-mode argument which did not feature the problem then went back to normal and started by removing Vaultpass and that seemed to do the trick.

Not sure how this behavior is a 20 year old bug, FF really should check if the prompt is already on-screen and bring attention to that instead of creating yet another master password prompt window in any scenario. This issue has lead to many cases of half typing a password in one field and then having keyboard focus stolen by the next master password popup for the second half many times as I open the browser. Glad to have my specific scenario worked around by not using that extension for the time being.

See Also: → 1778725

As a workaround "security.prompt_for_master_password_on_startup" like it is done in Thunderbird would fix this, so that it displays the prompt before starting Firefox. Maybe this is simpler to implement?

This mostly stopped happening for me lately, but today it happened again, maybe related to the recent update to v104 (on Windows).

After starting firefox (with restored tabs and windows), several primary password prompts appeared. About 6 or so, all one under the other.
Entering the (correct) password in one did not close the others.
Furthermore, as the other passwords were exactly below the first, it appeared that after clicking OK in the first dialog a new one appeared in its place, making the user think the password entered was not correct (there is no other feedback whether the password is correct or not, except that in case of wrong password the dialog reappears).

I did several restarts of firefox and the behavior is not consistent:

  • first I got half of dozen dialogs, as described above
  • on next start I got two
  • then I got none (until I opened a webpage that used a saved login)
  • then I got one dialog

Happened again right now, after resarting for the 104.0.1 update:

  • start firefox
  • open about:profiles
  • launch another profile
  • wait for the restored windows to appear

Result:

  • 3 password dialogs
    I entered a few leading characters of the password in dialog 1.
    I entered the password in dialog 2, clicked "Sign in", the dialog disappeared.
    I clicked "Sign in" in dialog 3, the dialog disappeared.
    I clicked "Sign in" in dialog 1, the dialog disappeared, bu a new one appeared.
    I clicked "Sign in" in the new dialog, the dialog disappeared, bu a new one appeared.
    So I entered my password again, clicked "Sign in", the dialog disappeared, and apparently the password was finally accepted.

firefox 105.0.1

after starting from about:profiles with "Launch profile in new browser" I get a lot of password dialogs. See screenshot. There were 9 dialog on the top left (all at same position; I dragged then down for the screenshot so all are visible) and one above a FF window (in the screen shot the right one).

A few days before I got 7 of them.

It seems since a few days this happens each time I start FF (with restoring the old session).
Note: seems, not confirmed. Currently I exited FF running the second profile, but there are firefox.exe processes in the background still running and I can't launch the profile until they go away. Will report later.

PS: As this bug is 20 years old and has over 400 comments and not a lot of developer activity, would it be better to close it and open a fresh bug for current issues?

(In reply to David Balažic from comment #413)

Note: seems, not confirmed. Currently I exited FF running the second profile, but there are firefox.exe processes in the background still running

Actually, FF was running as if I had not pressed ctrl+shift+Q , maybe I typed it into another window...

After closing that profile and starting it again (same way as above), there were zero primary password dialogs. Only one appeared after I opened a website that has a saved password.

So it seems pretty random...

Severity: normal → S3
See Also: → 1778449

Had a funny experience. Left a PC on over Tue-Wed-Thu the past week by mistake, with a locked screen and firefox on. When I came back there were 189 password prompts open on the screen and the taskbar had an interesting aspect. Now, I really start thinking that the only solution to this issue may be checking the ability to check the scripting abilities of the window manager (I understand that kwin supports scripting) and hack together a script that simply kills every second password prompt by firefox as soon as it is produced.

The severity field for this bug is relatively low, S3. However, the bug has 21 duplicates, 141 votes, 188 CCs and 14 See Also bugs.
:keeler, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dkeeler)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(dkeeler)

As the bug is still relevant, I took to liberty to readd the needinfo.

Also, new data:
After updating FF to 106.0, I got a "Password Required - Mozilla Firefox" dialog asking for the Primary Password. I started typing the password but after a second or two another same dialog appeared, took the focus and I continued typing in it. The new dialog is "modal" to the first one, that is: clicking on the old dialog activates the seconds one, flashing its window bar.
Also: opening a website with a saved password in another Firefox windows brings up another modal password dialog in that window.

Flags: needinfo?(dkeeler)

I think the current severity is appropriate.

Flags: needinfo?(dkeeler)
See Also: → 1768856

I am seeing similar behaviour in Thunderbird with a Primary Password set. If I run TB and leave the Primary Password prompt be for a couple of minutes (e.g., to do something else in a different application window), another Primary Password prompt is opened in the background.

I guess that the frequency of spawning of additional password prompt(s) may be influenced by the mail check intervals specified for the individual e-mail accounts (i.e., the longer the delay between mail checks, the lesser the frequency).

Summary: Should not display more than one "Master Password" prompts. → Should not display more than one "Primary Password" prompts.

@nvx2004 for thunderbird there is a nice workaroud at least: set security.prompt_for_master_password_on_startup to true. This makes the prompt appear before startup only once.

I think this would be a good workaround for firefox, too, if the underlying issue is too hard to fix. Just ask for the password on startup before doing anything else. It could be implemented so that if the user canceled it, it would go on with startup like before (probably triggering multiple prompt afterwards like it does now), but for users entering the password on startup the bug goes away.

@Markus: Hmm, I already have this preference set to true (has been as such by default). Maybe it helped in earlier Thunderbird versions, but it certainly does not fix the problem now...

@Markus & @nvx2004: I have TB running on two macs, same TB version, both with security.prompt_for_master_password_on_startup set to true. On the older machine, with the older profile, I now only get one prompt. And this started to be only one after some kind of recent changes (last six months or so). On the newer machine I get the startup prompt + a post-startup prompt. Same email accounts, same calendars set up. 🤷
So you both are right I suppose.

The previous implementation used some heavyweight, outdated, and unnecessary
components to achieve its effect. This patch greatly simplifies the
implementation.

Assignee: nobody → dkeeler

Unfortunately, since NSS can prompt for PKCS#11 authentication on the main
thread, the prompt in question results in a nested event loop, which means that
the prompt code can be re-entered and another prompt can appear before the
first is dealt with. As long as NSS can run on the main thread, this will
continue to be the case. Recently we've done a lot of work to prevent NSS
running on the main thread, but that work is by no means complete. In the
meantime, we can paper over this situation by cancelling any prompts that come
after one that is still in progress. This will cause some NSS operations to
fail in a way that should be recoverable by simply retrying them (e.g. the user
can refresh the page or close and re-open it).

Depends on D164279

Pushed by dkeeler@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/9a4f4672b74c re-implement PKCS#11 protected auth UI with modern components r=jschanck,fluent-reviewers,flod https://hg.mozilla.org/integration/autoland/rev/1d04423d3e5d cancel subsequent PKCS#11 password prompts if more than one happens concurrently r=jschanck

How will the 'refresh the page or close and re-open it' work with any extension syncing causes of Master Password Prompts ?

https://hg.mozilla.org/mozilla-central/rev/9a4f4672b74c
https://hg.mozilla.org/mozilla-central/rev/1d04423d3e5d

Status: REOPENED → RESOLVED
Closed: 16 years ago → 3 years ago
status-firefox110: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 110 Branch
Blocks: 1874609
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: