Closed Bug 39338 Opened 25 years ago Closed 25 years ago

Master Password defaults to "null" without warning the user.

Categories

(MailNews Core :: Security, defect, P3)

Product:
MailNews Core
Component:
Security
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 39653

People

(Reporter: esther, Assigned: morse)

References

Details

Using builds 2000-05-12 on win98, linux and mac, on the password dialog for the selected account, if the user checks the box "Remember this value" they don't get a Master Password dialog when it's the first time they've saved or remembered any password. I believe it's defaulting to "null" without warning the user that "null" is not secure. In the current spec it states: 1.) If the user has not yet created a Master Password the Password Manager Wizard is launched. 1. Launch Netscape 6 2. Create a New Profile and Launch it 3. Select Mail from the Tasks menu 4. Create a new mail account using he account wizard that comes up automatically. 5. When you get to the part with the "Save my Password" dialog, don't check the box (it shouldn't be in this dialog which is a different bug). 6. OK the new account and then select it in the mail window and click Get Msg 7. Password dialog comes up asking for account password with check box to "Remember this value", check the box. Result: you password is now save as "null" without bringing up the Password Manager Wizard which educates the user about the master password and explains that a null password is not as secure. Expected: The Password Manager Wizard should be launched. If we won't have the password manager wizard ready for PR2, we at least need to go back to the PR1 behavior otherwise we will be confusing the user by giving them what looks like the 4.7 behavior then taking it away again with the next release.
QA Contact: lchiang → esther
Keywords: nsbeta2
adding nsbeta2 to keywords
changing to p2
Priority: P3 → P2
Per the security meeting that was held on Friday (May 12), we decided not to do what you are asking for. So I'm marking the bug as invalid. Below are the minutes of that meeting, taken by Bob Lord. ******************** Today many of the people on this list attended a meeting to discuss the encryption technology to be used in N6 for SSO. Here are some notes from that meeting. Please read this and let me know if you have any corrections from the meeting, or comments on the outcome. We discussed 3 options. 1.Obscure as the default, with encryption as an option. 1.In this model, the default is obscuring the SSO data. By "obscuring", we mean an encoding scheme like base-64. Other encoding scheme which would be acceptable are uuencoding and DER encoding. 2.This is the code that is currently running (mostly). 3.The private keys are separate in the base, default case. There isn't the tight, one central solution that we've talked about. 4.Users can elect to migrate from "obscuring" to "encrypting" by visiting the prefs panel and checking the appropriate checkbox. 5.There are no Mozilla entanglements. 6.This work is done (needs polish) 7.There are no unknown UI tasks. 2.Ask user: obscure or encrypt 1.In this model, there is no default. When the user needs to save SSO data, N6 asks which he wants to use. If he selects "convenient", we use the obscuring system. 2.If he selects "secure", we use the key3.db solution. We then need to ask him to choose a key3.db password. 3.Ask user, but always use key3.db 1.In this model, we always use the key3.db, but there are still 2 modes: convenient and secure. 2.If you select "convenient" N6 will tell PSM to assign a null password to the key3.db (assuming you don't have a cert and key, which is true for 99% of users). 3.If you select "secure", PSM will show the password dialog box and you will be able to set a password. 4.There is no obscuring code in this model. 5.PSM must be installed The consensus of the team was to continue to implement option #1. Someone pointed out that there were legal and marketing concerns with this option. I'm not familiar with those concerns so I cannot comment completely, but I do think they are manageable. I need input from Laguardia, Murray, and Kent Walker to better understand the issues. We still have several tasks ahead of us. Some of those tasks include: 1.Make the "unlock your key.db file" password prompt less PSM centric. 2.Make that same prompt look less like the mail password prompt. 3.Change the set/change password dialog box to be less PSM centric. 4.Modify the obscuring code to be pure base-64, and not a faux-encryption scheme that XORs a fixed string. That's what I had in my notes. Please let me know what I missed. *********************** and here's an update to those minutes, written by Steve Elmer *********************** All options depend on the corrections to the password prompt that you mention at the end of the memo. Perhaps we're having another meeting to discuss that. Option 2 was the least favored because it has all the worst attributes of the other two options with no significant benefit over them. Option 3 has the additional issue that Mozilla needs a solution that doesn't depend on PSM. We suggested contributing the existing obscuring code and using a standard Commercial vs Mozilla strategy to account for the difference. This option was considered to be the most expensive to implement. ************************** and then I sent out the following message describing current status ****************************** Per the consensus reached at the meeting, I have just made the following changes and checked them in: 1. Obscuring now uses a straightforward base64 encoding 2. UI for switching between obscurring and encrypting consists of a single checkbox in the pref panel. Checking or unchecking that box and clicking OK will not only cause all future entries to observe that choice, but all entries that have already been saved are re-encoded using the new choice. In addition, I made the following two changes as well: 3. The switch between encrypting and obscuring is found in the menu as well as in the pref panel. Under tasks->privacy&security->password-manager I have added menu items for "encrypt stored data" and "obscure stored data". Only one of these menu items is enabled at any time. 4. The master password is always required (even if the database had been previously unlocked) in order to switch the encoding between encryption and obscuring or vice versa. This prevents an attacker from walking up to your machine when you are not looking and changing the encoding.
Status: NEW → RESOLVED
Closed: 25 years ago
Priority: P2 → P3
I guess I should mention who the attendees at the meeting were. Bob Lord Terry Hayes Steve Morse Suresh Duddi Steve Elmer and two people from the cartman team who's names I don't know.
Using Friday's build 2000-05-12 I don't see any way for the user to change from the default "null" master password to a "non-null" master password. When did you implement: "3. The switch between encrypting and obscuring is found in the menu as well as in the pref panel. Under tasks->privacy&security->password-manager I have added menu items for "encrypt stored data" and "obscure stored data". Only one of these menu items is enabled at any time." If we are going to stay with option 1 (a null password without warning), then this part has to be working. I went to most of the password meetings and I was under the impression that the default of "null" was an option still being discussed but not finalized for PR2. If we are going to stay with option 1 (a "null" password without warning), then #3 mentioned above, has to be working.
The changes I described above were implemented over the week-end, so you won't see them in Friday's build. Furthermore, the encryption code in SDR (secret decoder ring) is not being ready for prime time. Terry Hayes is working on that and plans to land everything before the Tuesday evening freeze. It should be mentioned that such encryption will work only if cartman is installed. If the user has not taken the extra step to install cartman, then he will have to be content with obscuring only (i.e., no master password).
cc'ing kmurray
Steve, I've downloaded Tue morning build 2000-05-17 and I now see the menu items: Encrypt Stored data and Obscure stored data. I have saved the password, and when I selected Encrypt stored data (to create a Master Password) I get this error "Unable to convert stored data". Is this the SDR problem that will be fixed by Tuesday evening? Also, I was told if the user installs the Commercial build using "Typical" installation, cartman is installed. Is this still true, if so I don't have to take an extra step right?
To answer your questions: 1. The "unable to convert stored data" is because SDR/cartman implementation is not yet complete. This is what I'm hoping will be completed by this evening. 2. Regarding whether or not cartman is installed in the "typical" installation, I'm not sure but I think it is not. However I have been told that cartman will definitely by included on the CD of the beta2 Netscape 6 release. Terry Hayes can best answer this.
*** Bug 26870 has been marked as a duplicate of this bug. ***
Reopening bug because my latest understanding was that we were *not* going to rely on a null password because of security concerns with Navigator's use of password manager. I will talk with Kevin and revisit this bug soon.
Status: RESOLVED → REOPENED
We decided that the solution for this issue is that the *null* value would work only if the verbiage in the dialog prompts was clear - that it clearly describes the impact of choosing non-secure over secure. Here's the relevant text from the minutes above: "All options depend on the corrections to the password prompt that you mention at the end of the memo. Perhaps we're having another meeting to discuss that." So, we need to discuss specifically what that verbiage is- howver, I believe it's solid in jglick's spec at http://gooey/client/5.0/specs/mail/Misc/SingleSignon.html I do believe there is inherent risk with using the *obscured* strategy, but if the prompts can properly educate the audience, then we should be ok.
*** This bug has been marked as a duplicate of 39653 ***
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → DUPLICATE
Verified duplicate
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.