322617 - Force master password prompt for every NR private key use

Status: NEW

(Firefox :: Security, defect)

Description

[Søren Munk Skrøder (extended hiatus)]

Disclaimer: I've very newbie with certificates and such...

Right now, when installing a digital signature (a PCKS12 certificate) one is only prompted for a password during the import/install...

Given the nature of a digital signature - a prompt for password should be mandatory at every usage...

worst case scenario : someone installs a digital signature certificate and applys password to install...
Result: everybody that gains access to that profile where the digital signature is installed have access to e.g. tax returns, internet banking .... 

Denmark has made a bit effort to get people to use digital signature -- but it's a bit of a loss if a user isn't required to enter the password every time the signature is used ...

Only safety workaround right now is to use "master password" - but afaik it's only used once per session - and not one time per signature...


Of course some certificates should just be persistenly active - (active without requiring password at every usage) --- but then an option should be added so that you can request a password for every time the certificate is used....

I can imagine that this perhaps is due to some usability/security tradeoff - but this is rendering digital signatures unsafe - resulting in bad PR

Comment 1

[Wan-Teh Chang]

I seem to remember that if the key usage or extended
key usage in the certificate says "non-repudiation"
in place of or in addition to "digital signature",
NSS will prompt for the master password for every
signing operation using that private key.  Is this
true?

Comment 2

[Julien Pierre]

Wan-Teh,

That's definitely not true, NSS doesn't do any such thing. But the poster can get the behavior he wants by switching the softoken to FIPS mode .
This can be done by going to Edit / Preferences / Privacy & Security / Certificates / Manage Security Devices / Enable FIPS .

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

The only mechanism by which NSS can cause the user to be prompted to login
is to demand login to the PKCS11 token, the so-called "master password".

The reporter didn't tell us what product he's using.  Moz 1.7? FF? TB?
Moz 1.x preferences give the user choices about how frequently he should 
be prompted for the master password.  Choices include:
- The first time it is needed
- Every time it is needed
- If it has not been used for [    ] minutes or longer
  (the user gets to fill in the blank)

I believe the second choice satisfies the user's requirement.

Perhaps FF or TB no longer offer those choices? 
In that case, this is a bug in those products that do not offer that choice,
not an NSS bug, IMO.

Comment 4

[Wan-Teh Chang]

When I put Firefox 1.5 RC2 in FIPS mode, I don't need
to enter my master password every time I send a signed
email.

Comment 5

[Søren Munk Skrøder (extended hiatus)]

Here follows a rough translation of an article that today adressed this issue

( For those who read danish - browse to : http://ing.dk/article/20060106/IT/101060040/-1/FORSIDE )

.............................................

Security of IT signature fails in succesful browser
---------------------------------------------------

An integral part of the security in the public digital signature which danes can use to sign important documents, is lost, if the signature is installed in the popular browser Firefox.


All that have access to the PC where the signature is installed can easily use and abuse the signature. Opposed to popular home/net banking sites, the user isn't prompted for a password when the documents are signed.

"It's fatal that this even can happen. This must not happen because with the digital signature someone could gain access to e.g. Skat (the danish tax office)" says Hanne Munkholm, systemsadministrator at the IT University of Denmark.

She was wondering why Firefox didn't prompt her for a password, when she connected to E-boks with the digital signature.

Firefox have in little over a year had a victory march across the globe. There is no statistics about how many of the danish digital signatures that are used in Firefox. But according to french analysis firm Xiti, 10 percent of the danes use the Firefox instead of other browsers like e.g. Internet Explorer, which isn't affected by this security breach.

The tight connection between the signature, the username and the password in Firefox makes the security poorer than that of the homebanking sites according to Peter Kruse from the IT security firm CSIS

Notably the security have been at the forefront with Digital Signatur (the public digital signature) which TDC (Denmarks largest telco) runs for the Danish Ministry of Science. Danes that live abroad can't aquire a signature without showing up at an embasy or a konsulate. Previously people even had to travel to Denmark to get one.

A guideline from TDC suggests that users create or change a password that is built into Firefox (the master password) to protect themselves from unauthorized access. Peter Kruse is however critisizing the guideline for being uncomprehensible and he assumes that only very few users have protected their browser as described in TDC's guideline.

"Firefox has more so found it's way to the general public, who have become tired of spyware, whereas it previously only was used by tech-savvy users"

Peter Kruse is also find the security of Firefox's own password somewhat lacking.

"There is a tool that can be used by anyone to crack the password - and if you combine it with the digital signature, you've got a dangerous cocktail"

TDC's department manager for the digital signature, Morten Storm Petersen, acknowlegdes that the security in Firefox is lower than in Microsoft's browser.

"We haven't been able to make things as robust as with Internet Explorer, because we haven't had the standards for how these other applications "talk" with the signature - these standards are lacking for alternative browsers like Firefox, Opera, Mozilla and Safari", he explains.

Morten Storm Petersen do however not think that users, that follow the TDC guideline have anything to fear, but TDC will together with the Danish Ministry of Science be checking if the guideline is good enough.

Palle H. Sørensen, cheif consultant at IT political center in the Ministry of Science explains that the guideline will be closely inspected and revised if the guideline is lacking.

Comment 6

[Søren Munk Skrøder (extended hiatus)]

Sorry about the product...  it's Firefox

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Søren,
Does FireFox not give the user the preference choices described in comment 3 ?
If not, this is a P1 FireFox bug.

Comment 8

[Julien Pierre]

Wan-Teh,

I assume you meant Thunderbird 1.5, not Firefox .
It doesn't work for me either in Mozilla suite 1.7.12 .
I believe this is a regression in the mail component. PSM is supposed to log in to the FIPS token again before signing each email when the token is in FIPS mode . At least it did back in the Mozilla 1.0 days.
Adding Kai to the cc list .

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

I just looked at the master password prefs UI in FF 1.5 for windows, and
found a comment in the dialog stating that you will be asked for the
master password once per session.  IOW, the FF UI designer has decided
that users should have no choices in this matter, and that once per
session is the right amount.

P1 FireFox bug, not NSS, IMO.

Comment 10

[Mike Connor [:mconnor]]

Nelson, why is it that the only solution you're offering is to force a master password prompt onto all password manager functions?  Forcing a user to enter their master password over and over again to protect a single certificate is using a hammer to squash an ant.  Is it not possible to prompt the user for the cert password on each use?  The password manager (in both seamonkey and Firefox) allows me to not store a password for a site I don't want to entrust to the password manager, why is something as sensitive as a digital certificate not afforded the same flexibility?  

Of course, if there is in fact a master password cracking tool that exists, then NSS is fatally flawed and should absolutely allow me to not store such a password, since storing the password is then essentially insecure.  Prompting every time for an easily cracked password presents a false sense of security, at best, and that's the most worrisome part of that article.

There's also the question (in response to mail you sent earlier) as to whether providing an option to always prompt can possibly satisfy a _requirement_ to always prompt, given that users can easily disable the prompt, or remove the master password entirely (assuming they even set one up in the first place).  If the requirement is to always prompt, then with your solution we have to require a master password and require the user to enter it every time, which has a negative effect on the other master password consumers like password manager.  Of course, if we had separate "master passwords" for certs and site passwords, we could enforce the master password/prompt always behaviour on digital certs without forcing that on users across the board.

Ideally, from a usability standpoint, we would be able to identify certs that should not have saved passwords and just never save those passwords.  If that's not possible, we at least need a "Never for this Certificate" option that would prevent NSS from storing the cert password or prompting to store it.

Comment 11

[Morten Svendsen]

- Method A -
1. Start firefox with a new clean profile
2. Import your Certificate
3. When importing, firefox ask you to set the master password before it ask you to give the password for the certificate.

- Method B -
1. Start firefox with a new clean profile.
2. Go to a site that uses a password as login and say yes when firefox ask you to save the password.
3. Import your certificate, and firefox will only ask you to give the password for the certificate and leave the master password unset.

Firefox should at least ensure that a master password is set when importing a certificate and not joust when following "method A".

A better solution would be to have a separate password for each personal certificate of the user, and ask for this password each time it is used.

The reason why the article is on the front-page of the newspaper "Ingeniøren" (is published ones a week "Friday" with a circulation of 65000) is that this "Digital signature" certificate supported by the Danish government and issued by TDC (http://tdc.com/), is used as the only required means of access to various sites including:
The citizens’ electronic mail-box (http://e-boks.dk/), where you get mail from your electricity company, the government, and so on.

Approximately 473000 certificates have been issued to just as many people in Denmark (5.5 mil pop).

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

I read through http://ing.dk/article/20060106/IT/101060040/-1/FORSIDE 
and all the replies to it, using the machine translator 
http://beta.visl.sdu.dk/visl/da/tools/translation_da2en.html
(which produced MUCH more readable results than Intertran's at
http://www.translation-guide.com/free_online_translators.php?from=Danish&to=English
) and found that there were two major gripes in the article and its followup
messages:
1. only being prompted for the master password at most once per session, and 
2. master password is apparently not required at all.  Users can import 
private keys without having any master password.  

The second item should probably be the subject of a second bug, but they're
very related, and hopefully will both get fixed together.

I reiterate that this is not an NSS bug.  
Moz App Suite (now Seamonkey) does not have these problems, AFAICT.  
So, I am changing this into a FireFox/Security bug.  
I will reply to Mike's comment 10 separately.  
The reply will be roughly as big as his comment.

Comment 13

[Mike Connor [:mconnor]]

(In reply to comment #12)
> 1. only being prompted for the master password at most once per session

The biggest problem from a UI design perspective is that the way toolkit's password manager was implemented, we can't have a master password that doesn't apply to the password manager too.  (Yes, this is problematic, but its where we are.)  Bug 322673 comes right out and asks for an option to not save the password for the cert instead of requiring a master password, so I feel quite certain in stating that the master password is not the only solution users are looking for.

If we were to link the password encryption into the OS (i.e. OS X keychain, winlogin-linked encryption, etc) instead of relying on the NSS master password, this would be really easy to address, since we could easily default to always asking for the remaining master password-driven actions, and the user wouldn't have to deal with multiple layers of unlocking access.

> 2. master password is apparently not required at all.  Users can import 
> private keys without having any master password.  

I'm guessing this is related to toolkit's password manager storing passwords encrypted against a blank password (instead of maintaining code for both obscuring + encrypted, as with xpfe).  The net result (this is from memory, its been over a year and I'm just getting into tracing this) is that there is a blank master password that is active, so we can in fact add a key with the blank master password being recognized as valid (and thus, no prompt, even though the code is the same PSM base impl that seamonkey uses).

> The second item should probably be the subject of a second bug, but they're
> very related, and hopefully will both get fixed together.

Its a separate bug, definitely, as detailed above.  The answer to issue #1 may solve this too, but not in the way you're envisioning.

Comment 14

[Nelson Bolyard (seldom reads bugmail)]

I have added a large comment to bug 322673, explaining what the master password
really is, and how it is really used.  Please read that before making further
comments here.  https://bugzilla.mozilla.org/show_bug.cgi?id=322673#c2

Now, here I want to speak to password cracking programs, and also on ways to 
decouple the master password frequency from the frequency of password manager
use.  

As explained in the comment to bug 322673, the master password is NOT used to 
encrypt any contents of the password file.  The key that encrypts and decrypts
the password manager's file of encrypted passwords is NOT derived from the 
master secret.  Therefore, it is IMPOSSIBLE to derive the master secret from
the contents of the password manager's password file alone.  

The password manager's password file is encrypted with a randomly generated
triple-DES key, which is stored in the software token's key storage, wherein
it is itself encrypted with another key, one that is derived from the master
password.  Any password-based encryption scheme may be vulnerable to 
dictionary attack if users use dictionary words as passwords.  

So, for a program to try to "crack" the master password, that program will
need both the password manager's password file, and the database that the
token uses to store encrypted keys.  The program would perform a dictionary
attack, using each trial dictionary word to attempt to decrypt the key in
the token, then taking the decrypted key and attempting to decrypt the 
password manager's password file with it.  If the trial master password
was correct, the password file will have been succesfully decrypted.  
Otherwise not.  If the attacker can get the victim's password manager file
AND the victim's token database files, then the attacker can mount an offline
attack on their contents.  

There are several ways in which the frequency of use of the master password
can be decoupled from the frequency of access to the password file.  
I'll discuss some of them in my next comment.

Comment 15

[Nelson Bolyard (seldom reads bugmail)]

Before describing a few ideas for decoupling "master password" frequency 
from password manager file access frequency, here is some more relevant background information on PKCS11.

1. Each key object in PKCS11 has a number of boolean attributes associated 
with it.  The values of these attributes are set at the time of the key's 
creation.

One attribute (the "token" attribute) determines the key's lifetime, either 
(a) a "temporary" or "session" key whose lifetime is no longer than that of 
the current running process, or (b) a "permanent" or "token" key that is 
preserved even after the running process has ended, and is available the
next time also.

Another boolean attribute (the "private" attribute) determines whether the 
user must be logged in (authenticated) to the token in order to use the key, 
or if the key can be used when no user is authenticated.  

2. NSS actually implements two software tokens today.  One (the "database" token) has "permanent" key storage, and requires authentication (the "master 
password") to access keys with the "private" attribute.  The other has no 
permanent key storage, does not store keys with the "private" attribute, and 
requires no authentication.

3. NSS's tokens support two modes of operation, normal and "FIPS" (Government 
approved).  In FIPS mode, only the database token is available, and it 
requires authentication to perform any operation, effectively treating all
keys as having the "private" attribute set.  Ideally, password manager will
work in either mode.

Ideas:

a) Have two separate Database tokens, each with a separate policy concerning
frequency of authentication.  One can be "once per session", and the other
can be "every time" or "after N minutes".  This is probably a lot of work, 
and it creates the possibility of two "master passwords", but it should work 
in either mode.

b) Each time the password manager's file key is needed, see if it is in the
non-database token, and if so, use it.  If not, get it out of the database
token and copy it to the other token as a non-private, temporary key.  
It may be necessary to login to the database token to do that, but it 
shouldn't have to be done again for the remainder of the process lifetime.  
To implement a policy of N minute maximum lifetime, simply delete the new
temporary copy every N minutes.  In FIPS mode, revert to getting it from
the database token every time.

c) there are numerous variants on b above.  One is to add another level of
key indirection.  Instead of storing the password file key in the database
token, wrap (encrypt) it with the key in the DB token, and store the encrypted
key in the password DB.  This approach avoids certain issues with "sensitive"
keys.

Comment 16

[Mike Connor [:mconnor]]

Ideally, I'd like to use two separate tokens since that gives us the most fine-grained control (for users and/or network administrators), but there's the question of how much work that is.  b) and c) both have the negative requirement of having to use the same "master password" for password manager if you want to use it to protect certs.

Having two "master passwords" is a wording/UI issue that I'm quite confident we can address across the mozilla apps.  Of course, there's only one current Mozilla app that's using the new password manager that really hits this issue (both Seamonkey and Thunderbird use wallet) so we're able to move relatively freely for now.

Comment 17

[Robert Relyea]

FIPS mode does not force logging in every time the key is used, FIPS mode forces logging in at least once before any crypto use.

Nelson correctly identified the option, though it appears the UI to set these options have been removed from FF/TB/Mozilla. I suspect the option can still be accessed as a pref.

NSS does not currently look at the non-repudiation bit and enforce differenct semantics, though the intention of the non-repudiation bit is to separate authentication tokens with authorization tokens.

The real issue here is diametrically opposed goals which have been pushing security. In general the goals is to all allow smooth, single signon. This means just enough authentication at the beginning to identify the user, and then allowing all authentication to happen as a result.

At the same time there is a desire to have additional intervention when high value operations are performed. FF/TB/Mozilla does this when you try to add or remove user certificates. There has been a separate push to have a way to verify certain types of transactions (like signing tax returns, checks, orders, etc.) where the signature would be tied to a non-repudiation certificate. Attempts have been made to try to add this functionality to the PKCS #11 spec with some limitted success, but typically have only been used in hardware tokens, where multiple password prompts can be enforced at the hardware level. Currently there is still debate on exactly how this should work.

Anyway separating 'turning on my password cache' and 'turn on my SSL authentication certificates' are both single sign-on type operations and should be combined. The trick is how to make those certs which are require special treatment... as well as how to provide all the required information to the user (like what it is that is actually being signed).

Comment 18

[Robert Relyea]

RE: Worse case scenario

>worst case scenario : someone installs a digital signature certificate and
> applys password to install...
>Result: everybody that gains access to that profile where the digital signature
> is installed have access to e.g. tax returns, internet banking .... 

Currently the mozilla suite requires the password to be entered at least once in the session before you can access private keys. This means gaining access to a profile is not the same as gaining access to the private key*.

*Major caveat. Software storage of keys and certs require some for to extra protection for the sensitive data (keys). That protect is usually provided with a Password derived key used to encrypted the keys in the database. NSS uses this scheme. The password derived key is only as strong as the user's password, which is usually significantly weaker than the keys it is used to protect. These databases, then, could be vunerable to dictionary attacks. This means you would never want to make a profile containing sensitive certificates accessible to others no matter what the semantics FF and TB use protect their access of the keys.

Comment 19

[Søren Munk Skrøder (extended hiatus)]

Hi all 

It's been quite quiet in this bug for some time

How is things progressing with this issue ...

Will it be possible to decouple the handling of certs / digital signatures from the same system that manages trivial site passwords? and will it be possible in the upcomming 2.0 ??

Comment 20

[Nelson Bolyard (seldom reads bugmail)]

OK, Here is a completely new proposed solution for this bug, based on a 
relatively new development in the crypto API standard used for our 
"master password".

Recap: The problem is that people with certain special signing certificates 
(so called "Non-Repudiation" or NR certs) want to be prompted for their 
master password EVERY TIME the key for such a cert is used, but they don't
want to be prompted every time that any other kind of key is used.  

Specifically, they don't want to be prompted every time the key for 
encrypting stored web site passwords is used. (That's the "Secret Decoder 
Ring" password used by password manager.) 

The PKCS#11 API has, until recently, had only one single password timeout
parameter that applied to all password protected keys, whether NR or SDR,
which meant that people either get prompted too often for SDR keys, or 
not often enough for NR keys.  

New development:  PKCS#11 v2.20 has a new key attribute named CKA_ALWAYS_AUTHENTICATE.  Any key with that attribute defined to TRUE will
force a password prompt every time it is needed, regardless of any other 
password timeout settings.  So, setting this attribute on keys for NR certs
should give the NR cert users what they want, while still allowing them to
have infrequent password prompts for other uses.

The catch?  
CKA_ALWAYS_AUTHENTICATE is not yet implemented anywhere in NSS or PSM.
That's the subject of bug 357025.  I've marked this bug as blocked by that 
one.  When that bug is done, then this bug can turn into a PSM bug to set
that attribute true on all NR certs.  

Comment 21

[Claudio Shah]

In my opinion Thunderbird 2.0.0.0 is doing a great job. It saves the passwords for POP3/SMTP without master password (the box "Use a master password to encrypt stored passwords" is not checked), but Tb asks every time for the master password if you use a certificate to sign emails (S/MIME). If you send an email without signing, it does not ask for the master password.

Why is Firefox 2.0.0.4 not doing exactly the same?

Comment 22

[Mike Schroepfer]

Nominating for blocking Firefox3.  This is a major issue in Denmark and may be a big barrier to adoption there.

Comment 23

[Justin Dolske [:Dolske]]

I think comments 15/16 are along the lines of what I've been ruminating over as being nice for Password Manager... In addition to simply disentangling Password Manager usage from certificate usage, using separate PKCS#11 tokens for each would allow the user to use different passwords (for token login) for each -- users shouldn't have to have the same "master password" for their lolcats.com login and banking certificate.

A variation on this would be for Password Manager to encrypt stored data with a key directly derived (via PKCS#5) from the "master password" entered by the user, instead of using it as a token login to access a secret key. [We would probably want an option to continue to use a secret key when the token isn't just a key3.db file sitting next to signons.txt in your FF profile. FIPS mode also throws an obvious wrench here.]

Comment 24

[Mike Beltzner [:beltzner, not reading bugmail]]

This is really-really wanted, but we're not comfortable blocking yet since we don't have a good sense of the impact. Priority should be given to investigating, though, as this is indeed a giant PITA for users in Europe.

Comment 25

[Rune S. Philosof]

(In reply to comment #22)
> This is a major issue in Denmark and may be a big barrier to adoption there.
 
Actually my wife just got herself a certificate and the issuer has apparently changed the installation method so that a password is always requested (also in firefox).
Unfortunately, I don't know how to change my old certificate, so that it behaves the same way.

So for new certificate users in Denmark the problem is solved somehow by the way the certificate is installed.

Comment 26

[Jesper Kristensen]

(In reply to comment #25)

You are right that the installation of TDC Digital Signatur automatically turns on the Master Password in Firefox. The problem is, that the current Master Password feature is not adequate for protecting the digital signature.

Here is a guide for the old installation method:
http://mozilladanmark.dk/wiki/Firefox/TDC_Digital_signatur#Installation_af_Digital_Signatur_i_PKCS.2312-format
The first part tells you how to turn on the Master Password.

Comment 27

[Rune S. Philosof]

(In reply to comment #26)
> You are right that the installation of TDC Digital Signatur automatically turns
> on the Master Password in Firefox. 

Well, TDC doesn't turn on the master password. As I can read further down the page you linked to, it installs a seperate security device which asks a password every time.
This actually gives me the wanted functionality, having one password for firefox's regular passwords (or no password) and having another for the certificate.

Comment 28

[hansen]

(In reply to comment #27)
Perfect! This exactly what it should do. I'm requesting a new certificate, so we might be able to resolve this bug.

Comment 29

[Jesper Kristensen]

(In reply to comment #27)
That sounds good. I didn't know they did that. But maybe that security device is the reason some people experience that their certificate store is destroyed when they install the signature. (Just guessing)

Comment 30

[hansen]

Okay. Got my new certificate today. And installed it.

It's installed the same way as in IE. Really easy. 3-step OK and two codes.
I don't need any Master Password stuff with the certificate - even better!

And even better. Now it works like it does in IE, with a tiny dialog-design difference. A dialog where you choose the certificate and IE's dialog way more user-friendly.
I'll attach the IE and Firefox dialogs.

This is a totally clean install. I have no idea how it would work with people already having an active certificate. I can test this, by requesting a new certificate for some of my friends.

Anyhow this issue should resolve itself, when the certificate runs out (1 year from install). This is a guess.

I would be okay with marking this bug as resolved and creating a new for the certificate selection dialog.

Comment 31

[hansen]

Attachment: Firefox unfriendly selection dialog

I had to blur most of the picture, since it contain personal information.

Comment 32

[hansen]

Attachment: IE6 user-friendly selection dialog (Danish text)

Comment 33

[Honza Bambas (:mayhemer)]

hansen: isn't this a dialog that asks you to select a personal certificate to identify you to a web site? If so, then it is something quit different from has been discussed in this bug.


Another option: NSS AFAIK supports adding a key (symmetric or asymmetric) wrapped by any symmetric key. Then, we could offer for NR (or any personal cert) option to protect the key by a "password", actually a PBE key. That PBE key lifetime might be customizable. This way users w/o master password (90+%) don't need to set a master password (and therefor to enter it during FF startup) but have an option to individually protect any key with whatever pass phrase. IE and windows key database IMHO do the same. Does it make sense?

Comment 34

[Nelson Bolyard (seldom reads bugmail)]

The last thing we want to do is create an environment in which there is a 
separate password needed for every key that is protected.  Having a single
"master" password means the user only needs to remember one password, and
this is unquestionably desirable.  The fact that FF UI forces users with 
master passwords to enter it at startup is a FF bug, not found in any other
mozilla product (TB, SM).

What this RFE requests, specifically, is that for private keys associated
with certain specific certificates, each and every use of the private key
will require the user to enter the password again for that use.  This 
ask-every-time behavior should be applied only to the private keys used
with those certs, and should not be applied to every secret in the DB.  
We want users to enter the password every time they use an "NR" cert, 
but not every time they need to decrypt a stored web site password.  

PKCS#11, the crypto API used in Mozilla products, defines such a capability.
It is the (nearly) ideal solution to this RFE. It is not yet implemented in
NSS.  The Specific NSS RFE for that feature is bug 357025, which blocks this bug.  The solution is to do that, but it requires man power we just don't 
have at the moment.  

Honza, you could help contribute to the implementation of bug 357025.

Comment 35

[Honza Bambas (:mayhemer)]

> Honza, you could help contribute to the implementation of bug 357025.

With pleasure.

Comment 36

[Jesper Kristensen]

(In reply to comment #33)
It makes sense to me, through i don't understand any of the technical terms.

Can you tell me why what has been discussed in this bug is different from what you described?

As described in comment 27, there has been created a workaround for Windows (which has its own bug 401292), so this bug is not as big an issue as before for Danish people on that platform.

(In reply to comment #34)
The request in this bug is that you can have a "password", which is only entered if the private certificate (or is it called key?) is needed. That means:
* No master password at startup
* No master password when you want to use a saved password
* Ability to "log out", that is the ability to require "password" prompt next time the certificate/key is needed

It would be ideal if you could protect two different certs/keys with a different "password", but that might be out of scope for this bug. The use case could be a family where everyone is using the same computer with the same OS user and the same Firefox profile, but they don't want eachother to be able to sign documents using another person's signature. E.g. a father which don't want his kids to be able to send in his tax report, but they can use his computer for everything else.

Comment 37

[jdevora]

In internet explorer, when you import a certificate you can choose it to have "extra security" and this will prompt for a password every time I want to use it.

I have to keep deleting and importing my private certificate, with it in Spain you can do ANY thing that you could do with your normal signature (banking, taxes, change my personal details etc).

It is very dangerous to allow any one to use it after you entered your master password.

Comment 38

[jdevora]

No progress in this very important privacy issue?

Comment 39

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 12 votes.
:serg, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 40

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

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.

Comment 41

[Andreas Nyback]

Problem still there.
Firefox 120.0.1
Only asks for master password once per firefox start. No way found to protect the user certificate with a password prompt at every use.

Howto:
Install a user .p12 certificate file.
Give the password (If it is created with password)
Certificate is installed.
Use the certificate as you like until next restart of firefox. If you had not set a master password, the user certificate will be available to use without password also between computer reboots/firefox restarts forever. No master password is the default setting.

Best solution; give the option to flag user certificates that the certificate password should be used at every access to certificate. The only way to do this now is to uninstall and reinstall the user certificate at every use. Not doable for a less experienced user.
Default setting should be to protect it at every access, but have a setting to choose, per certificate, if you like to only have master password, or no password at all.