(seamonkey port) option to show/display saved passwords

VERIFIED FIXED in mozilla1.7.4

Status

()

P3
enhancement
VERIFIED FIXED
15 years ago
11 years ago

People

(Reporter: jmd, Assigned: steffen.wilberg)

Tracking

({fixed-aviary1.0})

unspecified
mozilla1.7.4
fixed-aviary1.0
Points:
---
Bug Flags:
blocking-aviary1.0 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
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;
        }
}
(Assignee)

Comment 1

15 years ago
Before we add this, we should offer a simple way to specify a master password.
Adding dependency to bug 218694.
Severity: normal → enhancement
Depends on: 218694
OS: Linux → All
Hardware: PC → All
Summary: (seamonkey port) Password manager should have mode to display saved password → (seamonkey port) option to show/display saved passwords

Comment 2

15 years ago
We should go ahead and do this since it's just porting a fix from seamonkey.
Flags: blocking1.0+
Priority: -- → P3

Comment 3

15 years ago
(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
(Assignee)

Comment 4

15 years ago
Created attachment 151396 [details] [diff] [review]
patch
Assignee: bryner → steffen.wilberg
Status: NEW → ASSIGNED
(Assignee)

Comment 5

15 years ago
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.
Attachment #151396 - Flags: review?(bryner)

Comment 6

15 years ago
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.
(Assignee)

Comment 7

15 years ago
Juan, my patch needs to be reviewed first.
(Assignee)

Comment 8

15 years ago
Bitrot (locale files move) is near...
(Assignee)

Comment 9

15 years ago
Requesting blocking1.0RC1 because of localization impact.
Flags: blocking-aviary1.0RC1?
Attachment #151396 - Flags: review?(bryner) → review+
(Assignee)

Comment 10

15 years ago
I checked that in 2004-07-16 09:15. My first checkin ever!
Trunk checkin will have to wait until tinderboxen look greener there.
Flags: blocking-aviary1.0RC1?
Keywords: fixed-aviary1.0
Target Milestone: --- → Firefox1.0beta

Comment 11

15 years ago
*** 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
(Assignee)

Comment 13

15 years ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 14

15 years ago
(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!

(Assignee)

Comment 15

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

Comment 16

15 years ago
(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!
(Reporter)

Comment 17

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

Thanks Steffen!
Status: RESOLVED → VERIFIED
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.

(Assignee)

Comment 20

15 years ago
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
(Assignee)

Comment 22

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

Comment 23

15 years ago
(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

Comment 24

15 years ago
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
(Reporter)

Comment 25

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

Comment 26

14 years ago
(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 ).
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.