Closed
Bug 132323
Opened 23 years ago
Closed 16 years ago
Password Manager will not open when selected from toolbar
Categories
(SeaMonkey :: Passwords & Permissions, defect)
SeaMonkey
Passwords & Permissions
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: aharon, Unassigned)
References
Details
Attachments
(2 obsolete files)
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•23 years ago
|
||
0.9.5 is quite old. Can you get a recent build and see if it still exhibits this problem?
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 6•23 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•23 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 9•23 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•23 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•23 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•23 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: mailbox://nemo420@arbornet.org \=username=\ MDIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECHj++znwKiowBAghkJHYm5s7/g== *\=password=\ MDoEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECKSoV6V1PV7ABBCFta4pok8XIAX2r+WjEgxg .
Comment 13•23 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 manager. Hope that this helps. Michel
Comment 14•23 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•23 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•23 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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 19•23 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•23 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.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Comment 22•21 years ago
|
||
Always kept happening to me. Taking bug.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Updated•21 years ago
|
Assignee: morse → jgmyers
Status: REOPENED → NEW
Comment 23•21 years ago
|
||
Updated•21 years ago
|
Attachment #138552 -
Flags: review?(dwitte)
Comment 24•21 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.
Updated•21 years ago
|
Status: NEW → ASSIGNED
OS: Windows 2000 → All
Hardware: PC → All
Comment 25•21 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 password.
Attachment #138552 -
Flags: review?(dwitte)
Updated•21 years ago
|
Attachment #138592 -
Flags: review?(dwitte)
Updated•21 years ago
|
Target Milestone: --- → mozilla1.7alpha
Updated•21 years ago
|
Attachment #138592 -
Flags: review?(dwitte) → review?(neil.parkwaycc.co.uk)
Comment 27•21 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•21 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•21 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["@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•21 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.
Updated•20 years ago
|
Product: Browser → Seamonkey
Updated•17 years ago
|
Assignee: jgmyers → nobody
Status: ASSIGNED → NEW
QA Contact: tpreston
Target Milestone: mozilla1.7alpha → ---
Comment 31•16 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.
Status: NEW → RESOLVED
Closed: 23 years ago → 16 years ago
Resolution: --- → WONTFIX
Updated•15 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.
Description
•