Closed Bug 322673 Opened 14 years ago Closed 14 years ago
Password manager doesn't have an option NOT to remember PKCS ceritifcate passwords
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.
See also bug 322617
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
You need to log in before you can comment on or make changes to this bug.