Open Bug 838272 Opened 8 years ago Updated 6 months ago

Per-certificate password protection

Categories

(Thunderbird :: Security, defect)

17 Branch
x86
All
defect
Not set
normal

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: martin, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:18.0) Gecko/20100101 Firefox/18.0
Build ID: 20130116073211

Steps to reproduce:

This is feature request (wish). I am using TB 17 on Debian and Xubuntu. I cannot import personal certificate for e-mail signing AND password protect it (the certificate itself). I know about master password, that does not solve my problem.

It is important to have ability to password protect only selected certificates, because some types of certificates have according to law same power as your signature. These certificates must be very carefully protected.

Master password is not solution because once Thunderbird is running and first requests it (e.g. when connecting to SSL POP3/IMAP) everything is unlocked and anyone can send e-mail "I am hereby selling for 1 EUR house at ABC owned by DEF to XYZ .." which becomes properly signed without asking for a password.


Actual results:

...


Expected results:

MS-Windows allow "strong protection" of certificates (you are asked for a password before first use). Something similar would be very useful in TB under Linux.

More legal info: 

http://en.wikipedia.org/wiki/Digital_signatures_and_law#European_Union_and_the_European_Economic_Area
Component: Untriaged → Security

Kai, I couldn't find a duplicate of this. Does it make sense, as an enhancement request? Or is it impractical?

Flags: needinfo?(kaie)
OS: Windows XP → All

This remains one of Firefox's few, perennial, inexplicable, serious security failures.
We know that everything needs to be its own security perimeter now.
"Unlock once, use forever" is simply not acceptable for high-security items like certificate private keys.
In this case, as the person who opened this request seven years ago (!!) commented, Microsoft gets it right - the user can, per certificate, decide to require a per-certificate password to be used every time the certificate private key is requested to sign something.
This MUST be made practical, and implemented, in Firefox, finally.
thank you,
Jay Libove, CISSP, CIPP/US, CIPT, CISM(retired)

Jay, why do you mention Firefox?

This bug is about Thunderbird, and it seems the original reporter refers to digitally signing emails. I'm not aware of current mechanisms in Firefox to digitally sign documents with certificates.

Wayne, I'm not aware of a duplicate.

In the past, Firefox and Thunderbird had a shared preference, that controled how often the application asks for confirmation when requiring a private key stored in the NSS database (by requiring the user to enter the master password again).

In addition to today's default, which is "ask once, then don't ask again", it had offered the additional choices to "ask again after a timeout" and "ask every time".

I don't know when or why those features were removed. Probably a couple of years ago. Probably because people felt the feature was unnecessary or inconvenient.

However, the previous feature might have been insufficient to help with this request. We have only one global NSS store for all keys related to NSS, and only a global master password protection mechanism. This means, we cannot distinguish between unlocking it for the purpose of obtaining a remembered password (e.g. login to mail server after a disconnect) and when accessing a private key (as in the described scenario for digitally signing an email).

In other words, re-enabling the old choice to "ask every time" might fix the request, but it would also have the undesirable side effect of prompting the user every time on many other events.

I see two different requests here.

(a) each certificate's private key should be protected with a separate password

(b) prompt the user each time the application wishes to create a digital signature

Regarding (a), NSS doesn't support implementing that easily. We'd have to use separate key stores for each certificate. And even if NSS supported it, it would still be insufficient in the near future, once we introduce OpenPGP support, because those secret keys for digital signing will be managed separately from the NSS library.

This means, in order to implement (a), we'd have to implement an additional password protection mechanism at the Thunderbird application level.

Regarding (b), we'd also have to implement it as an application level feature in Thunderbird. Without (a), the keys might already be unlocked, we could still require the user to perform an additional confirmation, even by entering a user defined password that we associate with each stored secret key.

Note that my summary is a description of my understanding of this request, and potential ideas on how to implement them. At this time it's not clear what priority this should get.

Flags: needinfo?(kaie)

(In reply to Kai Engert (:KaiE:) from comment #3)

Jay, why do you mention Firefox?

This bug is about Thunderbird, and it seems the original reporter refers to digitally signing emails. I'm not aware of current mechanisms in Firefox to digitally sign documents with certificates.

Oh, bugger... Well, as you point out in your next reply, there had been Thunderbird & Firefox commonality.
My interest happens to be in Firefox, as I don't use Thunderbird, however, the problem is identical in both.
The current default (as you point out) is (a bit too) convenient, to the point of inadequately secure, regardless of whether in Thunderbird or in Firefox. So, on principle, I do support the argument for Thunderbird too.

That said, it appears that I need to find or open a similar bug report for Firefox.

thanks for pointing out that I am apparently in the wrong virtual reality here....
-Jay

Interesting. Maybe I wasn't in the wrong virtual reality :-}
I just posted a "Firefox" bug about this (https://bugzilla.mozilla.org/show_bug.cgi?id=1624317) and it promptly got placed in the NSS component...

See Also: → 1624317
You need to log in before you can comment on or make changes to this bug.