User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.1.5) Gecko/20091103 SUSE/3.5.5-2.1 Firefox/3.5.5 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.1.5) Gecko/20091130 SUSE/3.0.0-12.1 Thunderbird/3.0 In TB2 (and before that I used SeaMonkey, Mozilla mail/news, and right back to Netscape) there was a separate 'Software Security Device' password to protect access to my S/MIME certificates and which was only required to sign mail or read my encrypted mail. This was separate to the Master Password that protected stored signon passwords - which I never used. In TB3 I deduce that the master password does both jobs. But I have to enter it every time on start-up - even though I rarely use S/MIME and have no requirement to protect my stored passwords. If this is by design, it seems to me to be a regressive change. Reproducible: Always Steps to Reproduce: 1. Import an S/MIME signing certificate. 2. Note that I can sign email and view my encrypted email without providing a software security device password (unlike TB2) - which is an obvious security risk. 3. Add a master password. Actual Results: I get "Please enter master password for Software Security Device" whenever I start TB3 even though I rarely need to access my certificate. Note that I do not download mail at startup so I don't even need to access my stored server passwords immediately either - but that's not what this bug is about. Expected Results: The Software Security Device password should only be requested when I need to access my personal S/MIME certificate to sign or view encrypted email. It should be mandatory. This should be separate from the master password which protects stored server passwords. There should be two passwords as in TB2 and formerly. The one that protects the S/MIME certificate should be mandatory (it currently isn't in TB3) and is more important because a signed email is personal and non-repudiable to must not be sent by anyone having access to the account. If two people use the same account only the owner should have access to the S/MIME certificate. The master password protecting the stored server signon passwords is less important - I never bothered with one.

I completely agree here. This is a terrible change that opens up a poor security choice by design. Users are now forced to decide if they want the security device protected or the automated login ability but not both. Most people will likely want the automated email retrieval and will open their protected store. As a typical user I'm more than willing to allow non-password access to retrieving email because in general it's not critical to security. Most messages are plain text anyway. But when I do have something important that is encrypted then it now has been forced into the open (if I want automated email retrieval) or I am forced to use a master password for mail retrieval. In my opinion this is a bug or at least a terribly insecure regression. Most security problems are "social engineering" problems and this choice forces users to use either a master password or force an open certificate store, when if fact the best option would be a choice so that users can have automated email but still maintain secure certificates for when an email is encrypted. Now, any user who chooses no master password for email retrieval has (perhaps unknowingly) also unprotected their certificate store so that signed/encrypted emails can be sent. Bad design! Not only that but after only a few days problem messages are already all over the various forums with people wondering why they need a security device password that they never did before. And as a result there are replies telling everyone how to disable/reset the master password - hence, everyone now knows the way to circumvent the whole system anyway. Whoa!

I've reverted to TB 2 and won't be upgrading until this is fixed. There should be two separate passwords one for retrieval and one for security devices as they are a different class and higher importance. Many users may be inclined to drop the master password and this now exposes any certificates they have. Is anyone looking into this issue at all?

I don't think anything changed in this area between TB2 and TB3. So you understand what's going on, I invite you to look at these docs: http://www.mozilla.org/projects/security/pki/jss/javadoc/org/mozilla/jss/crypto/SecretDecoderRing.html http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/28ae4c3d7c37870e/19f6cdb3b79ceec8?#19f6cdb3b79ceec8 Hope this info clears up what's going on. Also, double-check to make sure you are not in FIPS mode. http://support.mozilla.com/en-US/kb/Configuring+Firefox+for+FIPS+140-2?bl=n&s=fips

I have no idea what's changed in the programming. I haven't looked at nor do I intend to look at that. I'm a user not a programmer. But I can say that I installed TB3 and it very definitely was using the same password for both master password and for the security device. You get prompted for it at program start, and once you enter it the certificate store is wide open. If you don't enter it then the certificates are unavailable. I tried to fix this by following the steps outlined on "GetSatisfaction" to remove the master password. After that I found that with no password the certificates were wide open to use. I looked for a place to add a password to just the certificates (software security device) and if I recall I found an option and added a password. After that it was once again being used as the master password for account logins. I worked on this for a couple hours and then gave up and removed TB3 and reinstalled TB2. TB2 worked as expected with a different password for each the account logins and the certificates. I have no master password but I am prompted for a password for any signing/encryption use. There is an option for managing the password for security devices. So I have checked this and verified that TB3 and TB2 are different. I've posted a warning on the Ubuntu forum for users that are interested in secure use of TB with certificates, that they need to be aware there is this insecurity in TB3 now which didn't exist before. No one seems to be interested. I guess not many people use certificates in TB so that's why this is flying completely below the radar. Your response seems to be to deny the problem. I didn't just make this up for your entertainment. Regarding FIPS, I have no idea. I never changed or made any selection related to anything called FIPS. If there is some internal option called FIPS in TB3 that has been mistakenly triggered by the upgrade then I suppose that could cause a problem, but it's not something I ever saw or made any choice about. Perhaps rather than denying the problem someone else could check this out and verify the behavioral changes regarding security devices between TB2 and TB3. I've already confirmed for myself that from a user point of view this is what happens.

I do think it has changed between TB2 and TB3. Since raising this bug I read bug 506638. That's Seamonkey bug but it applies to TB too: https://bugzilla.mozilla.org/show_bug.cgi?id=506638#c56 If fact, I think that what I hit when upgrading TB2 > TB3 was a case of bug 506638 that isn't mentioned there AFAICS - I did not have my passwords encrypted but I did have a 'master password' (though SM/TB2 never called it that - it was a 'master security device password') because I have personal S/MIME certificates. So it's changed for me because I can't have what I had in TB2: a password protecting my personal certificate but my ordinary mail server passwords unencrypted. My understanding of bug 506638 is that when I add a master password it encrypts my server passwords. Is that wrong? (I don't /think/ I am in FIPS mode in TB3 at the moment because I do not have a master password - having removed it. If I click 'Enable FIPS' it asks me to add a master password. I can experiment with that if you want put I don't think it's germane.)

This is probably a dupe of bug 492509. TB now uses the same password backend as the browser, so both products share this same problem. I agree this needs to be changed, I've started some refactoring to pave the way with bug 499417, but much work and many issues remain.

Dave/Justin, thank you for the links. I now agree with you that there has been a change. I keep forgetting how long ago TB2 development started. And it's interesting to note how the wording has changed over the years (Master Password, Software Security Device, etc.). As noted in bug 506638 and in the documents I posted above, the symmetric key that encrypts web/email passwords is stored in the key3.db file. That's the file that also contains private keys for your personal certificates. So if you assign a password to that file, you are protecting both your private keys as well as the key that is used to encrypt your web/email passwords. As for FIPS mode, if the button invites you to "enable" it, then you are not in FIPS mode. The reason I mentioned this is that sometimes people click around and get themselves into FIPS mode, and that mode requires that you have a master password, and also requires you to enter it when the NSS crypto system initializes, which is often at launch time. And that's not what they want. I agree that this bug is a dup of bug 492509. Justin, please be careful with any changes involving the cryptographic protection of any of these keys. You'll want to run your design ideas past the NSS team so you don't accidentally trip over any FIPS-140 regulations and compliance issues, or other gotchas. Also, since this is a shared code-base with Firefox, you'll need to think more broadly than TB. Hope this info helps.

This problem isn't platform specific. I have the same problem on Mac OS 10.6.x

I think I experience the exact opposite of this problem. Things work as expected in TB 3.0 but not in 2.11: I am using Ubuntu 10.04 and Thunderbird 3.17. My wife is using Ubuntu 8.04 and Thunderbird 2.11. We wish to exchange secure email with a third party. As a test case, we each downloaded certificates from StartSSL and installed them in Thunderbird and tried to send encrypted messages to each other. We both sent each other digitally signed messages and now can send each other encrypted messages. However, we find the following. When she sends me an encrypted message, I am able to read it without further intervention. When I send her an encrypted message, she has to enter her certificate password once per Thunderbird session in order to be able to read encrypted messages from me. Is this a bug in Thunderbird 2.11 or is something else going on? I'd be grateful if someone could tell me.

(In reply to comment #9) > I think I experience the exact opposite of this problem. Things work as > expected in TB 3.0 but not in 2.11: > > I am using Ubuntu 10.04 and Thunderbird 3.17. > My wife is using Ubuntu 8.04 and Thunderbird 2.11. Those versions don't make sense. Do you really mean 3.1.7 and 2.0.0.11? Please note that Thunderbird 2.x is no longer supported.

You are right about the version numbers, it is 3.1.7 and 2.0.0.11? I don't expect support for 2.x but I would be appreciative if someone could confirm that this was a known issue in 2.x. I have had a go at searching through bugzilla (that's how I found this bug), and got too many hits that may or may not be related. This problem is surprisingly difficult to describe, there seem to be so many variables that it's just hard to pin down.

Is there anything new about this issue? I use currently Thunderbird 7.0.1 and still the use of the certificates is only protected by the master password, not by a password especially for the S/MIME-certificates.

I started getting this popup a few days ago and I was thinking it was a virus infection on my Mac - esp as I seem to be getting pop advertisements recently I hadn't been getting before. FIRST QUESTION: Is this bug owned by Mozilla (would make sense as it appears only when firefox has focus)?? For God's sake, if Mozilla/Firefox is going to use pop up requests for ANYTHING would you, at least, make clear the request is coming from Firefox/Mozilla and not some trojan? I also have various extensions downloaded from Mozilla, but I don't see any obvious connection (Noscript, Privacy Badger, Ghostery, Adblock Plus, Language Tool (spelling/grammar). I think that is it. I HAVE, in approx the same timeframe, begun using Firefox's password manager. But the popup doesn't SAY it is the password manager...and I see no obvious connection as the popup request comes at seemingly random times when I change tabs, but not in an obvious login screen where passwords are being requested. Anyway, please let me know if this is Mozilla's bug. It is driving me buggy not knowing what I am dealing with here. I just started an Avast scan.

Umm. I should be more clear. I came to this forum by doing a search on the phrase ""Please enter master password for software security device". I do have thunderbird on my machine and it is possible it was running in the background, although I am not clear on that. I also downloaded Seamonkey a few days ago. This popup request comes when I change tabs in FIREFOX and I figured it was related to Firefox. I will not run either thunderbird nor seamonkey for a few days, at least not in the background, and see if the popup disappears. As I said, it would be nice if Mozilla code would identify itself explicity in a case like this.

(In reply to tanstaaf1 from comment #14) This bug is a Thunderbird-specific request, so if your issue is with Firefox, this is not your bug.