132323 - Password Manager will not open when selected from toolbar

Status: RESOLVED WONTFIX

(SeaMonkey :: Passwords & Permissions, defect)

Description

[Aharon]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+)
Gecko/20020319
BuildID:    2002031903

When selecting from the toolbar:
tasks-> Privacy & Security -> Password Manager -> Manage Stored Passwords

no Password Manager opens. My passwords are getting stored (Mozilla remembers
the passwords I've saved for various sites), but the management of the passwords
through "Manage Stored Passwords" is impossible.

This might be connected to another problem I've been experiencing in Mozilla
(since I upgraded from Netscape 6.2 to Moz 0.9.5). If I select:

Edit -> Preferences -> Privacy & Security -> Passwords

and uncheck "Use encryption when storing sensitive data", I get this Alert
message: "Unable to Convert Stored Data".



Reproducible: Always
Steps to Reproduce:
This is specualtion since I'm unsure what exactly is causing the error...

1. Create a profile in Netscape 6.2
2. Select Encrypt Stored Data in Privacy preferences
3. Uninstall Netscape
4. Install Mozilla
5. Try to access password manager ->Manage Stored Passwords, or change
encryption setting in Privacy Prefs

Comment 1

[Stephen P. Morse]

0.9.5 is quite old.  Can you get a recent build and see if it still exhibits 
this problem?

Comment 2

[Aharon]

I'm using 0.9.9 (build id, 2002011903). I've experienced this bug since 0.9.5,
but to clarify, I'm not using 0.9.5.

Comment 3

[Stephen P. Morse]

I believe you meant 2002031903 instead of 2002011903 in your last comment.

Comment 4

[Aharon]

You're right. BuildID: 2002031903

Comment 5

[Jimmy Sieben]

I see this problem on RC2!

Why does it happen?

Comment 6

[Adam Monsen]

Can someone please mark this as new/confirmed? I'm also unable to open the
password manager with rc2 (Build ID: 2002051013).

Comment 7

[Michael Smith]

In 1.0/RC2: Tools/Password Manager/Manage Stored Passwords does not open the
passwords window.
NB: I set the security option to "Use encryption". If I try to uncheck this
choice I get the error "Unable to convert data".
I had the same problem in RC1.

Comment 8

[Stephen P. Morse]

Can you reproduce the problem starting with a fresh profile?

Comment 9

[Adam Monsen]

No. With a fresh profile, I am able to get the "Password Manager" dialog to 
come up by clicking on Tools->Password Manager->Manage Stored Passwords. Dangit.

Is there any way to reset or forget all my stored passwords?

Comment 10

[Stephen P. Morse]

Of course you can reset them by using the password-manager dialog, but I presume 
you are asking the question for the case when you can't get to the dialog.  In 
that case, go to your profile directory and delete the file with a .s suffix.

Can you try experimenting with your bad profile to see what part of it is 
causing the problem.

Comment 11

[Adam Monsen]

> Can you try experimenting with your bad profile
> to see what part of it is causing the problem.

I've tried many different things, but I really don't know how to effectively
debug this issue. Is there anything in particular that I should try?

FWIW, I tried changing the theme from "Pinball" back to "Classic", but this
didn't allow me to access the Password Manager dialog.

I *think* the problem (not being able to bring up the dialog) started when I
began to use mozilla for mail. I'll definitely post an update if I can figure
out how to reproduce this.

Comment 12

[Michael Smith]

Having read the last comments, I tried to reproduce the problem.
- created new profile with Netscape 6
- started Mozilla with this new profile, checked that I had access to the
password dialog => ok
- opened the .s file and saw that it was text data with obvious structure,
decided to copy the data from my normal profile to the new profile
- restarted mozilla => NO dialog
- removed most of the password data from the .s file, restarted mozilla => ok
- added step by step the password data => some are OK, some produce the problem.
(I think that it this step it's interesting, what do you think ?)

I think that all "bad" data are more recent than others. At least I am sure that
the latests saved password is "bad".

When I look at the data, ALL those which produce the problem have
characteristic, that NONE of the others have. It looks like the
obscuring/encrypting algorithm was changed at some point and that either the new
one produce the problem, or maybe the mix of the two.

Here is a "bad" data (if ever someone can decrypt it I don't care ;) but I am
confident that it's not possible (BTW: Am I right ?). The caracteristics are :
 - much longer data (in my list, "good" password are shorter than 40 characters,
"bad" ones are all at least 73 characters long)
 - string is like M.*AAAAAAAA in all "bad" data.

At some point, as I said, I switched from "obscuring" to "crypted" data. Maybe
this is part of the cause of the problem ? To finish, I know that this "bad"
data is good anyway, because the mailer is able to use it to open the mailbox.

Sample "bad" data:

mailbox://[e-mail]
\=username=\
MDIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECHj++znwKiowBAghkJHYm5s7/g==
*\=password=\
MDoEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECKSoV6V1PV7ABBCFta4pok8XIAX2r+WjEgxg
.

Comment 13

[Michael Smith]

Ok, I have both to infirm part of the previous comment and add maybe interesting
new information.
It seems that the copy/paste did not work for newly encrypted data not because
the data is wrong but because the encrypting function depends on the profile :
the old data could be copy/pasted, but not the new one. This is the reason why
all new data looked wrong in my test.
So I went back to my normal profile, and did the following :
 - make backup of .s file
 - open it with editor and remove all "new data".
 - restart mozilla : I can access the password list !
NB: I think that something was wrong with the version of mozilla when I changed
the policy to encrypted, because there is mixed old and new data there. The
current version changed all data to new format when I changed the policy in my
test profile. This is why I did the following.

 - set the policy back to "obscured" : this time, no error.
 - set the policy again to "crypted" : the content of the file changes and all
data is now in "new" style.
 - restart mozilla : password list is still available (good!).
 - try to add one by one the previously removed data, restart and test the
password manager at each step : all BUT one are ok !

I think that at some time the encryption was a bit broken and that I added the
faulty data with this version. I can't absolutely not say when. But I think that
we can draw 2 conclusions :
 - short term, if someone (meonkeys) has this problem, he may try to find and
cut the badly encrypted data, hopefully only one or few ones are bad
(chirurgical correction). Don't forget to restart mozilla before each test.
 - mozilla should be able to SKIP the bad data when it found some, why not with
error message asking to delete it, instead of aborting the access to password
manager.

Hope that this helps.
Michel

Comment 14

[Stephen P. Morse]

So if I'm hearing your correctly, the work-around is to decrypt and the 
reencrypt the passwords, and then everything works well.  Is that right?

Comment 15

[Michael Smith]

Not exactly. The main point is to find which password is bad, and remove it.
After that it should works.

The decrypt/encrypt step was only to get eventually a completely encrypted file
instead of the mix that I had, and can be done only when the bad password is
removed. Reasons to do that are : it's safer because I don't know if this mix
will be supported in the future, and for security since in the mix some data are
only obscured.

Comment 16

[John G. Myers]

Also happens on 2002061308 trunk build on Mac (as well as 0.9.9 and 1.0).  I've
been having this problem for a while.

Comment 17

[John G. Myers]

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

Comment 18

[John G. Myers]

(that's Mac OS X)

Comment 19

[Martin Sch]

Same here with 1.0final.
After checking "Use encryption", it works now. There was a mix of encrypted and
unencrypted passwords in the .s file.

Maybe the title of the bug should be changed because it has got nothing to do
with the toolbar.

Comment 20

[Stephen P. Morse]

It sounds like there might have been a problem at one time with bad things being 
put into the password-manager file.  But as far as I can tell from the above 
comments, that problem is not happening anymore.  That is, with a fresh profile 
this problem is not reproducible.

So I'm closing this out as works-for-me.  If someone is able to reproduce it 
starting from a fresh profile (and not cutting and pasting values from some 
previous bad profile), then please reopen this and give the sequence of steps.

Comment 21

[Stephen P. Morse]

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

Comment 22

[John G. Myers]

Always kept happening to me.  Taking bug.

Comment 23

[John G. Myers]

Attachment: Proposed fix

Comment 24

[John G. Myers]

The problem was that any problem decrypting any entry in the store would cause
the dialog to fail to appear, with no feedback to the user.  The proposed patch
instead ignores those entries that cannot be decrypted.  I also did some cleanup
and debug-only instrumentation.

Comment 25

[John G. Myers]

Comment on attachment 138552 [details] [diff] [review]
Proposed fix

Needs work--does not handle the case where the user cancels entering the master
password.

Comment 26

[John G. Myers]

Attachment: Updated fix

Comment 27

[[e-mail]]

If the master password is necessary to open the password manager, then shouldn't
we deliberately request the master password, so that we know that subsequent
errors are caused by corrupt password entries?

Comment 28

[John G. Myers]

I'm not aware of a way to deliberately ask for the master password.  One asks
for whatever operation one wants and if the implementation of that operation
requires the master password, it prompts for it.

It's also concievable that passwords could be stored on a hardware crypto
device, which would have a separate password.

So I would say that explicitly triggering the master password prompt would be
inappropriately exposing an implementation detail through an interface.  The
patch's approach of using a distinguishable error code is cleaner.

Comment 29

[[e-mail]]

Well, the wallet.crypto pref will be set if encryption is on;
then you ned to get the token:
var tokendb = Components.classes["@mozilla.org/security/pk11tokendb;1"]
                        .createInstance(Components.interfaces.nsIPK11TokenDB);
var token = tokendb.getInternalKeyToken();
Then you have access to e.g. token.isLoggedIn(); token.checkPassword(sPassword);
token.login(bForce);

Comment 30

[John G. Myers]

I still don't see how the method suggested in comment 29 is better than the
proposed patch.  It appears to be more fragile, more dependent on details of the
underlying implementation of the interface.  Instead of poking around things
that are used indirectly by the implementation of the interface you want to use,
far simpler to do what you want and then handle any resulting errors.

Comment 31

[Philip Chee]

The wallet code is dead. On trunk we are now using the toolkit login manager. If you still see the problem please file a new bug against the Login Manager component. Thanks.