User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:22.214.171.124) Gecko/20060508 Firefox/126.96.36.199 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; de; rv:188.8.131.52) Gecko/20060508 Firefox/184.108.40.206 When using the master password feature, all email/usenet accounts are protected so that a third person is unable to use thunderbird without knowing the password. It also protects all accounts from being accessed so that the third person cannot read private emails. But even with activated master password, a third person is able to read all subject lines of the first email account when it was accessed the last time - this can be a security risk, as the third person is able to guess the content of the emails I have received. Reproducible: Always Expected Results: To increase the security, thunderbird should not display and email subjects or senders (or maybe even also no account names) before the master password was entered correctly.
Seting mail.password_protect_local_cache to to true fixes this, no?
This fixes it, but now I am not able to save the passwords for my accounts. Thunderbird is always asking for the password for the first account (which is IMAP), so now I have to enter the Master Password and the password for the first account. My other accounts (1x IMAP + 1x POP + 1x NNTP) do not ask for the passwords. Besides of that I would recommend to set mail.password_protect_local_cache to true by default as the standard user does not know the "about:config" feature. IMO this would increase the basic security of Thunderbird.
The passwords in Thunderbird are used to unlock access to your mail on the server, they have nothing to do with locally saved data. If someone has access to your machine they have access to your files. Use OS-level protections (for example, screensaver with password lock, logging out when done) to protect local files. This pref option hides the display in thunderbird, but the data is still present on your disk in an easily discoverable location.
Assignee: dveditz → bienvenu
If you have a master password, it's reasonable to allow passwords to be saved even when "mail.password_protect_local_cache" is true, and to show the message list after the master password is entered.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Security problem with the master password → allow passwords to be saved in master password file if it's password protected, even if "mail.password_protect_local_cache" is true
(In reply to comment #3) > The passwords in Thunderbird are used to unlock access to your mail on the > server, they have nothing to do with locally saved data. I understand that, but the "normal" user does not know about how to access the files locally saved. Besides of that, when using IMAP and not POP, only very little data is stored locally. To increase security I would recommend to set mail.password_protect_local_cache by default to true. Ok, I guess bugzilla is the wrong area to discuss this, I will start a thread about this in one of the mailinglists.
From the dupe, the code to poke around with if someone is up for it should be around here: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/mailnews/base/util/nsMsgIncomingServer.cpp&rev=1.259&mark=740#733
I had been typing my password and been wondering why Thunderbird didn't prompt me to save it for some time now, until it began to bother too much and I started looking for the cause. Apparently setting this pref was the trigger. Disabling the pref, entering and saving the password and enabling the pref seems to work, but then I get two master password prompts, even in TB220.127.116.11 and on the next start I get again a master password prompt and a prompt for the imap account... I'll have to keep the pref disabled until this is fixed :-(
In bug 239131 and its dependencies we have now changed how mail.password_protect_local_cache such that it will work only if you have a master password. You can therefore store your mail server passwords in the file normally. Therefore this is fixed by bug 239131 and bug 433316
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.