Password Manager will not open when selected from toolbar



Passwords & Permissions
16 years ago
8 years ago


(Reporter: Aharon, Unassigned)


Firefox Tracking Flags

(Not tracked)



(2 obsolete attachments)



16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+)
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

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

Comment 2

16 years ago
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

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

Comment 4

16 years ago
You're right. BuildID: 2002031903

Comment 5

16 years ago
I see this problem on RC2!

Why does it happen?

Comment 6

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

Comment 7

16 years ago
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

16 years ago
Can you reproduce the problem starting with a fresh profile?

Comment 9

16 years ago
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

16 years ago
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

16 years ago
> 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

16 years ago
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:


Comment 13

16 years ago
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

Hope that this helps.

Comment 14

16 years ago
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

16 years ago
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

16 years ago
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.
Ever confirmed: true

Comment 17

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

Comment 18

16 years ago
(that's Mac OS X)

Comment 19

16 years ago
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

16 years ago
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.
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME

Comment 21

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

Comment 22

14 years ago
Always kept happening to me.  Taking bug.
Resolution: WORKSFORME → ---


14 years ago
Assignee: morse → jgmyers

Comment 23

14 years ago
Created attachment 138552 [details] [diff] [review]
Proposed fix


14 years ago
Attachment #138552 - Flags: review?(dwitte)

Comment 24

14 years ago
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.


14 years ago
OS: Windows 2000 → All
Hardware: PC → All

Comment 25

14 years ago
Comment on attachment 138552 [details] [diff] [review]
Proposed fix

Needs work--does not handle the case where the user cancels entering the master
Attachment #138552 - Flags: review?(dwitte)

Comment 26

14 years ago
Created attachment 138592 [details] [diff] [review]
Updated fix
Attachment #138552 - Attachment is obsolete: true


14 years ago
Attachment #138592 - Flags: review?(dwitte)


14 years ago
Target Milestone: --- → mozilla1.7alpha


14 years ago
Attachment #138592 - Flags: review?(dwitte) → review?(

Comment 27

14 years ago
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

14 years ago
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

14 years ago
Well, the wallet.crypto pref will be set if encryption is on;
then you ned to get the token:
var tokendb = Components.classes[";1"]
var token = tokendb.getInternalKeyToken();
Then you have access to e.g. token.isLoggedIn(); token.checkPassword(sPassword);

Comment 30

14 years ago
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.
Product: Browser → Seamonkey
Assignee: jgmyers → nobody
QA Contact: tpreston
Target Milestone: mozilla1.7alpha → ---

Comment 31

9 years ago
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.
Last Resolved: 16 years ago9 years ago
Resolution: --- → WONTFIX


8 years ago
Attachment #138592 - Attachment is obsolete: true
Attachment #138592 - Flags: review?(neil)
You need to log in before you can comment on or make changes to this bug.