Closed Bug 322673 Opened 14 years ago Closed 14 years ago

Password manager doesn't have an option NOT to remember PKCS ceritifcate passwords

Categories

(Toolkit :: Password Manager, enhancement)

x86
Linux
enhancement
Not set

Tracking

()

RESOLVED INVALID

People

(Reporter: rune, Unassigned)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

When importing a PKCS #12 certificate as the Danish Digital Signature, You're asked to put in the password which the password manager remebers. There should be an option NOT to remember this password as there are for webpages passwords.

In Denmark everybody can get a Digital Signature that is legal binding as much as a normal signature. You can protect the certificate with a master password, but this makes browsing the web more difficult, that you use the same MP for all the none significant passwords you have.

The only truly secure option is to install and delete the certificate everytime you use is.

Reproducible: Always

Steps to Reproduce:
1.Install a PCKS certificate
2.Do NOT type in password
3."The password was wrong"



Expected Results:  
An option "Save password in password storrage?" For every certificate.
The original bug description appears to be based on a mistaken understanding
of how keys are managed in mozilla products, such as FireFox.  I will 
explain how key storage is really managed in mozilla products.  I will 
refer to mozilla (rather than to fireFox) because all mozilla's NSS-based
products work the same way.

PKCS12 files contain private keys and public key certificates.  PKCS12 file 
contents are typically encrypted with a key that is derived from a password.  
Each PKCS12 file may have its own password.  

When mozilla products use keys for encryption and decryption, they do NOT get those keys from PKCS12 files each time.  Mozilla products do not use PKCS12 files for storage of keys and certificates that are routinely used.  Instead,
mozilla products store keys and certificates in cryptographic devices (such 
as smart cards and cryptographic USB fobs), or virtual crypto devices (which
may be purely software).  These physical or virtual cryptographic devices 
are called "tokens".  PKCS11 is an international standard interface for 
access to cryptographic tokens.  PKCS11 tokens provide cryptographic engines
and/or protected key storage.  mozilla uses PKCS11 exclusively as the only 
way that it accesses tokens.  All encryption done by mozilla is done in 
PKCS11 tokens, using keys stored in those PKCS11 tokens.  mozilla cannot use
a key unless and until that key is in one of the PKCS11 tokens to which 
mozilla has access.

Tokens may (and typically do) require some form of user authentication before
allowing the user to access the stored keys and/or algorithms.  The user 
authentication may be done with passwords or PIN pads or even fingerprints
or retinal scanners.  In the PKCS11 model of tokens, when the user 
authenticates to the token, the user gets access to all the keys stored in 
the token.  The user is authenticating to the token, not entering a password
for individual keys.  We say that the user logs in to the token, and may also
log out of it.  

mozilla products all come with a built-in software virtual token.  They can 
also be configured to work with other physical tokens.  The built-in token
uses a password for authentication.  From that password is derived an 
encryption key that the token uses internally to encrypt the other keys
that it stores.  The encrypted token password itself is not stored in the
token anywhere.  All the keys stored in mozilla's token are protected by
the same key, which is derived from the token's password.

Some (all?) of the mozilla apps have chosen to use the term "master password" 
to describe the password for the built-in token.

When a certificate and private key are "imported" from a PKCS12 file into
mozilla's built-in token's key storage, the user is asked for the PKCS12 
file password, so that the contents of the PKCS12 file may be decrypted, 
and thereafter used in its raw unencrypted form.  The user is also asked
for the password for mmozilla's built-in token.  The decrypted data is then 
entered into mozilla's built-in token key storage, where it is encrypted 
with another key, the one derived from the token's "master password". 
In other words, mozilla makes a copy of the (decrypted) contents of the 
PKCS12 file, and stores that copy encrypted in mozilla's built-in crypto token.

After the contents of a PKCS12 file have been imported into mozilla's 
crypto token, mozilla has no further use of the PKCS12 file.  The PKCS12
file may be removed from the system.  mozilla does not remember the 
password that was used to protect the contents of the PKCS12 file.  
Thereafter the only password required to access the keys in mozilla's token
key storage is the token's password.  

mozilla's password manager uses the token to generate a random encryption
key for encrypting passwords.  That random key is stored in the token's
key storage.  The random key is not derived from the master password.
To use that random key for encrypting or decrypting passwords, mozilla 
must authenticate to the token using the token's "master password". 
Then the token will willingly use the stored random key to encrypt or 
decrypt passwords.  

BTW, Denmark citizens don't get a "Digital Signature", rather they get a
public key certificate and a private key.  Using those things, the citizens
can then make their own digital signatures.  FireFox does exactly that 
when doing SSL client authentication to national web sites.  Thunderbird
does exactly that when generating signed emails.  Each SSL connection and
each signed email gets its own unique digital signature, all derived from
the user's private key, and verifiable with the user's certificate.

So, in summary, mozilla does not remember passwords for users' PKCS12 files.
Therefore, the request in this bug, to be able to not remember those
passwords, is how mozilla is already behaving.
"So, in summary, mozilla does not remember passwords for users' PKCS12 files.
Therefore, the request in this bug, to be able to not remember those
passwords, is how mozilla is already behaving."

IMHO that's reading the summary very litteraly, isn't it..?

To get to the bottom of this issue, this is how (i think) it should work for the user :

1) Users should be prompted for a password on each usage of the PKCS12 digital signature (a prompt per session or per install will not do)
WHY: because it's paramount that some form of user interaction happens upon signing a document digitally

2) That password shouldn't be coupled in with the same password system that manages trivial passwords (to e.g. chat-sites, etc) or can be disabled/Empty-Stringed
WHY: Because in order to accomplish (1) one would have to set "ask every time" on the master password. When users repeatedly have to enter a password - even for trivial sites, passwords tend to become trivial... Furthermore one could be looking over your shoulder when accessing that low-priority site...

Therfore my suggestion would be for the password that grants access to a digital signature to be kept out of the master password token system...

Why can't Firefox/Mozilla just log into the PKCS12 digital signature on every usage ? (instead of copying the unencrypted signature into Mozillas built-in token and risk having a trivial password governing it....)
Nelson, thanks for the incredibly lucid explanation.  This is probably something that should get dumped on devmo for the non-crypto people.

Rune, I'm going to resolve this as invalid.  As Nelson explained, the PKCS12 file is just a container (think password-protected zip file) for the actual cert, which has no password.

Bug 322617 will cover separating password manager from the "master password" system in such a way that we can have separate settings for certs/keys and passwords.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.