4.72 KB, patch
|Details | Diff | Splinter Review|
4.36 KB, patch
|Details | Diff | Splinter Review|
1016 bytes, patch
|Details | Diff | Splinter Review|
Edit->Preferences->Privacy and Security->Master Passwords I can't figure out how to get rid of my master password once I've set one. I can change it, but I can't get rid of it. I'm running Mozilla build 2001 062204 on Win98.
The Change Password dialog should allow null passwords. Currently, there is no way to revert to a null password. I think that's because the JS code looks to make sure both new password fields are the same, and non-null. The requested change is to allow null passwords. When we do this, I'd like to add a JS alert saying something like: -- Warning! You have deleted your Master Password, thereby eliminating the protection of your private keys and your stored web passwords. -- That needs work, but you get the idea.
Priority: -- → P3
Target Milestone: --- → 2.1
Moving all P3 and P4 bugs targetted to 2.1 to future.
Target Milestone: 2.1 → Future
removing nsenterprise keyword from PSM bugs with target milestone of future.
Mass assigning QA to ckritzer.
QA Contact: junruh → ckritzer
Netscape 6.1 Suggestion Primary Browser: ntsc61 Language: English Component: Security Suggestion Category: Improvements Issues Details: I would like to be able to disable the Master Password in Security without losing all my info. I find it very inconvenient to enter a password every time I log on to get my mail. I wish I had never used it to begin with, because now I'm stuck with it. I also miss the green arrow, and sound of my choice when I receive new mail. I do, however like many other features of Netscape 6.1.
P3 -> P1 There have been several complaints from people who want to have a null password after having set one. I'm also going to set it back to PSM 2.1 (from Future) for another look. Stephane will probably want to move it back out to Future because of time constraints, but I want to give it one last shot before giving up.
Priority: P3 → P1
Target Milestone: Future → 2.1
Assignee: ddrinan → kai.engert
Fixing this bug results in additional changes in application behaviour. Currently, a user is *forced* to set a password the first time some private data are stored, e.g. a private key. At this time, the application does not allow the user to set an empty password. The OK is simply disabled when there is no password entered. If we add a patch to allow the user to clear the password later, it doesn't make sense to enforce the user to set one. I therefore was required to change these cases, too. I'm attaching a suggested implementation. This seems to work, but I'm not sure whether I really thought of all combinations that might occur. Bob (Relyea): To implement this corretly, I need to decide whether the PKCS#11 slot has already been initialized, but is currently using an empty password. Please have a look at nsPKCS11Slot::GetStatus at http://lxr.mozilla.org/mozilla/source/security/manager/ssl/src/nsPKCS11Slot.cpp#166 Can I assume that the SLOT_READY case is what I want? Or do you suggest, that we should use a different combinations of PK11_xxx calls to be sure that the slot is initialized but has an empty password? I don't want to use the PK11_CheckPassword function to find out, as I fear, if we reuse the new code in the future for hardware tokens, multiple unsuccessful calls to PK11_CheckPassword with the wrong password might deactivate a hardware token.
Status: NEW → ASSIGNED
Sean, can you please have a look at the bottom of the patch? I'm adding three strings, which are combined at runtime into two different messages. I.e. either message 1+3 or 2+3. (I thought it will be easier for localization if we reuse string 3). Do you want to change these strings?
NSS supports the internal key database in 3 states: 1) Uninitiallized. There is no password. The key database cannot be used until it is initialized. 2) Initialized with a NULL password (""). In this case the token is treated as a public token and keys can be accesses without the use of a password. From an application point of view you never get a password prompt. 3) Initialized with a password. In this case the token is treated as a private token, and must be 'logged-in' before access to the keys are granted. This 3 state system was used to preserve the pre-pkcs #11 communicator semantics, where you are asked to provide a password on the first use of an uninitialized database. At that time you could choose to run with no password. If PSM is trying to avoid state '2', that would explain the UI which prevents NULL passwords. So how can you tell the three states? There are to functions PK11_NeedLogin(slot) and PK11_NeedUserInit(slot) They are set as follows: State 1: PK11_NeedLogin PR_TRUE PK11_NeedUserInit PR_TRUE State 2: PK11_NeedLogin PR_FALSE PK11_NeedUserInit PR_FALSE State 3: PK11_NeedLogin PR_TRUE PK11_NeedUserInit PR_FALSE bob
+pw_erased_ok=Warning! You have deleted your Master Password. - fine +pw_not_wanted=Warning! You have decided to not use a Master Password. Change to "You have decided not to use a Master Password." +pw_empty_warning=Your private keys and your stored web passwords will have no protection. Change to "Your stored web and email passwords, form data, and private keys will not be encrypted."
When the code with "status = SLOT_READY" is reached, we know for sure that we have not state 1 and not state 3, as PK11_NeedLogin must be PR_FALSE. Although there is no explicit check for the value of PR_NeedUserInit, we can assure it must be PR_FALSE from Bob's explanation. I'll therefore continue to use SLOT_READY to decide this token has a null password. I'm adding Sean's changes. David, can you please review the next patch?
adding patch review keywords.
Keywords: patch, review
adding nsentreprise to keywords.
Keywords: nsenterprise → nsenterprise+
Patch checked into trunk. I don't close this bug yet, as we want this patch on the branch, too.
a=asa for checkin to 0.9.4 branch (Why isn't PSM using the wonderful new Patch Tracker for tracking review and super-review?)
Created attachment 48486 [details] [diff] [review] Changing one word in user interface string only "not encrypted" => "not protected"
ssaux said: "The last alert tells the user that the web passwords will not be encrypted anymore. We should change that to "not protected" . The reality is that they are encrypted, but with a null password." That's the reason for the new patch.
Comment on attachment 48486 [details] [diff] [review] Changing one word in user interface string only "not encrypted" => "not protected" sr=blizzard
Checked in to trunk and branch, closing bug.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Eww, encrypted with a null password? That doesn't sound great for performance...
Performance of what? Signing/Unwrap? The 256 byte triple-DES decrypt of a private key is more than swamped by 128 byte RSA sign/unwrap operation. The neglible performance cost of this operation is weighed against the benefits of simpler code (keys are always encrypted), and the extra security inside the client process because the nature of the private key is obscurred from key scanning programs except when the key is in actual use.
Verified on build: 2001-09-13-0.9.4 platform: Win NT Under Edit->Preferences->Privacy and Security->Master Passwords I selected the null password and got the security warning.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.