Port fix from bug 78754. At least when Mozilla used simple Base64 encoding, my simple perl script could unobscure the contents of the password file. Now the new obscuring code is too annoying for me to figure out to update my script, and I can't get at my passwords at all. Incredibly frustrating. Here is "mozpwview", for anyone with passwords still Base64'd and needing to access them: use MIME::Base64; while (<>) { if (s/^~//) { chomp; print decode_base64($_) . "\n"; } else { print; } }

Before we add this, we should offer a simple way to specify a master password. Adding dependency to bug 218694.

We should go ahead and do this since it's just porting a fix from seamonkey.

(In reply to comment #2) > We should go ahead and do this since it's just porting a fix from seamonkey. (In reply to comment #2) > We should go ahead and do this since it's just porting a fix from seamonkey. One request, if it is not too much of a job to accomplish, would be to incorporate the ability to print out a copy of the password list and/or save as a text file so that it can be taken with you...there are occasions when having a printed copy of my site passwords would be very useful when accessing the web from a machine other than my usual one. Thanks

Comment on attachment 151396 [details] [diff] [review] patch This is basically a port of attachment 143220 [details] [diff] [review], which is the "updated final patch" for bug 78754 for Seamonkey. I also included the whitespace changes. I inserted the button labeling code in Startup() above "// load password manager items" because LoadSignons() throws an exception if you cancel the master password prompt upon opening the password manager. We've got to label the buttons before that. I'll leave catching the exception to another bug. I removed <script src="chrome://global/content/strres.js"/> from passwordManager.xul since we don't use srGetStrBundle(). I had to rework ConfirmShowPasswords() because we don't use the pref "wallet.crypto". I was able to simplify the function a bit. The code works fine with and without a master password being set, I only hope I got all the comments right.

Steffen Wilberg , why don't include this code into FireFox nightly builds to test it ? I like so much this option in Mozilla 1.7 and is very useful , this is the reason i still use the Mozilla suite instead of FireFox.

Juan, my patch needs to be reviewed first.

Bitrot (locale files move) is near...

Requesting blocking1.0RC1 because of localization impact.

I checked that in 2004-07-16 09:15. My first checkin ever! Trunk checkin will have to wait until tinderboxen look greener there.

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

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040716 Firefox/0.9.1+ WFM

Trunk checkin 2004-07-19 06:37. The only modification I had to make was in passwordManager.js: - } else if (column=="passwordCol") { + } else if (column.id=="passwordCol") { -> fixed.

(In reply to comment #13) > Trunk checkin 2004-07-19 06:37. > > The only modification I had to make was in passwordManager.js: > - } else if (column=="passwordCol") { > + } else if (column.id=="passwordCol") { > > -> fixed. First off, thanks for your work on this. Question: Is this incorporated in the FF 20040719 trunk build for OS X? When I go to Firefox>Preferences>Privacy>Saved Passwords>View Saved Passwords>Show Passwords>Yes I still get an empty/blank window even though I know that there are saved passwords (I logged in to post this question using that build and the user ID and password appeared automatically). I looked in my user.js file and did not see any language other than some entries I have previously made to include URL autofill and to enable the use of my default email client when clicking on links while browsing in FF. One comment as to the accessibility of this is that there are a many more clicks to gain access to this (assuming that the way I described above is the way it is supposed to be accessed) than in Mozilla where I click on Tools>Password Manager (selecting Manage Passwords from its submenu)>Show Passwords>Yes. This amounts to four clicks for Mozilla and six for FF with FF requiring two clicks to close the window instead of one for Mozilla. I do not know what the "conventions" are as to where matters such as this are to be displayed, but the way this is done in Mozilla seems, to me at least, to be less complicated. Lastly, is there a plan to allow the web sites/User ID/Passwords to be printed to a hard copy at some point in time? I believe that there is more use for this capability than people realize. Cheers!

> Question: Is this incorporated in the FF 20040719 trunk build for OS X? If you see the "Show Passwords" button: yes. The dialog starts with two columns, "Site" and "Username". Upon clicking the "Show Passwords" button, it displays a third column with the corresponding passwords. I don't know why the dialog is empty for you. It isn't for me. Passwords are stored in signons.txt, not user.js. The question whether to really show passwords is done for security reasons, and it's in Mozilla as well. The user might want to reconsider showing passwords when somebody is looking over his shoulder. If there's a master password specified, one has to enter it at this point. > Lastly, is there a plan to allow the web sites/User ID/Passwords to be printed > to a hard copy at some point in time? None that I know of. And there doesn't seem to be a bug for that. Feel free to file one.

(In reply to comment #15) > > Question: Is this incorporated in the FF 20040719 trunk build for OS X? > If you see the "Show Passwords" button: yes. > > The dialog starts with two columns, "Site" and "Username". Upon clicking the > "Show Passwords" button, it displays a third column with the corresponding > passwords. > > I don't know why the dialog is empty for you. It isn't for me. Passwords are > stored in signons.txt, not user.js. > > The question whether to really show passwords is done for security reasons, and > it's in Mozilla as well. The user might want to reconsider showing passwords > when somebody is looking over his shoulder. If there's a master password > specified, one has to enter it at this point. > > > Lastly, is there a plan to allow the web sites/User ID/Passwords to be printed > > to a hard copy at some point in time? > None that I know of. And there doesn't seem to be a bug for that. Feel free to > file one. I had all of the right columns & etc showing up but simply got a blank screen even though passwords were obviously being used. There was no signons.txt file present in the profile and I tried adding one and so on without success. I did a reinstallation (after removing the existing profile) and imported data, but it did not work out. I just cleared the FF profiles and did a new install without importing anything. A signons.txt file appeared after I went to a web site that required a log in and had done a manual log in as I was not recognized (no old cookies & etc). It looks like the problem was in using an existing/old profile that also had the XXXXXXXX.s file which contained the passwords (in encrypted form I believe). I have brought in my user.js file and old bookmarks and will just manually (re)enter passwords as I go to other sites. All works well now. I do not know if others would like to have the ability to printout their passwords/user IDs or not. It seems useful to me, both as a backup and to take with me if I am going somewhere else where I will have access to a different computer. What do you think? Thanks again!

V w/ Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040725 Firefox/0.9.1+ Thanks Steffen!

I have the same problem with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040809 Firefox/0.9.1+ updated vrom CVS on Aug 09. I do have a signons.txt, it is obviously used, but no entries are shown in the window. Unfortunately I did not check when the displaying of stored passwords vanished. There must be a different way in interpreting the signons.txt when actually looking up for passwords and when displaying in the stored password window. As I even don't remember all my passwords, I'd be happy if someone can tell me how to get access to my stored passwords.

> As I even don't remember all my passwords, I'd be happy if someone can tell me > how to get access to my stored passwords. > OK, at least the perl script helps me, so I could revisit all pages and reenter my data, but that'll take quite some time. Probably there was some problem importing an old firefox profile, but then I wonder why the passwords ar still corectly used but not displayed in the window.

Please file a new bug, product Firefox, component Password Manager. This bug did not introduce the Password Manager, it merely added an option in it to show "Password" in addition to "Site" and "Username".

For those who are intested: Bug was already entered: #249761. Did add a comment there. Thanks for the hint. Should have checked the whole Bug DB first. Gerhard

Please don't remove people from the cc list, thanks.

(In reply to comment #22) Steffen, After a period of the password manager and view saved passwords working I have encountered the blank screen problem again. This time there is absolutely nothing in any of the three columns. No site name, no user name, no saved password. It continued through a number of nightly updates and I also tried a complete reinstallation creating a new profile on one or two occasions. I have since just done the upgrade installation to the trunk nightly builds. As of the 20040812 Trunk build for OS X this condition persists. (I am still using OS 10.3.4 and so I do not believe that there has been any change of the OS that would have affected the situation.) Can you shed any light on this situation? Thanks, Richard

Apologies to all if I am making this comment in the wrong place: I feel it is a REALLY BAD IDEA (for maintaining security in an environment with lots of under-informed users--like an office or school) to have a [Show Passwords] button! Many users assume that their "managed passwords" are kept in an encrypted file and never concealed except in their use with the specified web-site. Having the button available makes it way too easy for co-workers to have a quick peek at passwords of someone who is away from their desk--even for 30 seconds. This option is in TB too, and should be removed from both. The only way this option should be allowed is if it is via an extension that must be installed by an administrator who chooses to do so--but even that seems like too much of a hole. Sorry about the rant, but this would definitely get in the way of our organization migrating from Eudora/IE to TB/FF. Douglas Swiggum, University of Wisconsin

> Many users assume that their "managed passwords" are kept in an encrypted file What do you base this estimate of users on? And why would they assume something that's: 1) not alluded to or told to them anywhere in Firefox, 2) impossible. Now that master password UI has been added, the first time you tell Firefox to store a password for you, it should tell or prompt you to set a master password if you want your stored data secured. If it doesn't explain this to users, file a bug. > quick peek at passwords of someone who is away from their desk--even for 30s This has always been possible. They step away from their desk, I transfer their single-signon file to my PC, and unobscure it at my leisure. There's just no way around this fact. Don't tell a program you run to save sensitive information, and then either leave the data itself unprotected, or leave your PC unprotected. (Even a master password without a secured PC or trustable coworkers is of little use--key loggers, trojans, etc are trivial to install). The very slightly additional ease of access to this information for undetermined malicious coworkers is certainly worth the MUCH easier access of a user's information to the user themselves. The only question is, why does it take a click on "Show Passwords" and then an annoying confirmation dialog to show information that's already available.

(In reply to comment #25) > The very slightly additional ease of access to this information for undetermined > malicious coworkers is certainly worth the MUCH easier access of a user's > information to the user themselves. The only question is, why does it take a > click on "Show Passwords" and then an annoying confirmation dialog to show > information that's already available. I wrote the original implementation for this in Mozilla and (thankfully) others picked it up and got it to where it is today. The decision to have an annoying confirmation dialog pop up seemed useful when a user did not yet have a master password established. Then, they don't click the 'Show Passwords' button and BANG! suddenly all of their passwords are in plainview (as in my comment http://bugzilla.mozilla.org/show_bug.cgi?id=78754#c20 ).