234776 - Possible to export cert with empty password

Status: RESOLVED WORKSFORME

(Core Graveyard :: Security: UI, defect)

Description

[Patryk Szczyglowski]

User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113

It is possible to export user's own certificates with an empty password. The
Export dialog box doesn't check if the user erased typed password with
backspace, thus not graying out OK button.

Reproducible: Always
Steps to Reproduce:
1. Preferences
2. Privacy and Security
3. Certificates
4. Your certificates
5. (Select some certificates)
6. Backup Copy
7. (put some password and then erase it with backspace)
Actual Results:  
The OK button is not grayed out, user is able to save certificates to disk with
no password.

Expected Results:  
OK Button grayed out.

Comment 1

[Kai Engert (:KaiE:)]

The culprit is mozilla/security/manager/pki/resources/content/password.js
in
function checkPasswords()

The condition here
  if (pw1 == pw2){
    ok.setAttribute("disabled","false");

should be changed to
  if ((pw1.length > 0) && (pw1 == pw2))

Comment 2

[Kai Engert (:KaiE:)]

Attachment: Patch v1

This patch fixes the problem for me.

Comment 3

[[e-mail]]

Comment on attachment 174178 [details] [diff] [review]
Patch v1

This will prevent you from changing your master password to blank, as that
dialog uses the same function. I assume that wasn't intentional?

Comment 4

[Kai Engert (:KaiE:)]

You're right, I was not intending a side effect for the master password behaviour.
But this throws up another question. 

If we already allow an empty master password,
why should we forbid to export a certificate with no password?

We probably should be consistent.

Either we protect users from making bad decisions (which we obviously do not -
since we allow the empty master password)

or we should allow empty passwords when exporting, too.

Comment 5

[John G. Myers]

I see no problem with allowing an empty password for export.

Comment 6

[Patryk Szczyglowski]

But I do ... there is an inconsistence in the dialog handling, at start, the OK
button is disabled, later - enabled. I think it should be disabled all the time,
when the user attempts to export with no password. Sometimes, someone else has
to decide what is good for user.

Comment 7

[Patryk Szczyglowski]

Anything is going with this bug?

Comment 8

[Kai Engert (:KaiE:)]

I see that firefox currently:
- enables the OK button all the time
- allows the empty password

Ok, what about the following salomonic solution?

Let's do the same in Seamonkey, however, when the user selects the empty password, let's show an additional warning dialog box. If the user confirms the use of the empty password, fine. Otherwise we go back and the user can use a better one.

Comment 9

[Kai Engert (:KaiE:)]

*** Bug 342387 has been marked as a duplicate of this bug. ***

Comment 10

[Jean-Baptiste Quenot]

It's ok for me, do not disable the OK button, but add an extra warning just to be sure that leaving blank is intentional.

Comment 11

[Kai Engert (:KaiE:)]

reassign bug owner.
mass-update-kaie-20120918

Comment 13

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

AFAICT from comment 8, Firefox behaves the way we want it to right now. If Seamonkey wants to change the behavior, they'll have to do so in their tree.