Closed Bug 24909 Opened 25 years ago Closed 25 years ago

Shouldn't be able to see "Display Signons" w/o providing db key/unlocking

Categories

(SeaMonkey :: Passwords & Permissions, defect, P3)

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: kevinyen, Assigned: morse)

Details

Currently, w/o unlocking the db with the key, I can choose "Display Signons" and 
see the sites and signon names.

This is a security problem.  Better if choossing "Display Signons" prompts for 
db key.

thx
kevin
This was by design.  The passwords are not displayed, only the list of sites and 
usernames.  So there is no security problem.

This information is also stored in plaintext on the disk.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WONTFIX
hhmmm, not sure if this is best.  Two reasons:
1. Is it clear to user what's key protected and what isn't?  It has to be 
simple.
2. What about sites for which even the user name is sensitive, confidential, 
such as SSN or account #?

Reopening until we're comfortable w/ the discussion.

thx,
kevin
Status: RESOLVED → REOPENED
Well that implies there is something for you to do here so I'm assigning the bug 
to you.
Assignee: morse → kevinyen
Status: REOPENED → NEW
Continuing discussions...

Steve -- can you please share your thinking on my comments two sections above?

thx,
kevin
The site itself didn't think that information was as sensitive as the passwords 
because it displayed it as cleartext on the screen (as opposed to the asterisks 
that it uses when it collects passwords).

But I can see the point that you are making.  Right now anyone can walk up to 
the machine and bring up the signon viewer.  And if the username field happens 
to be the users social-security number, that information will be visible.

I don't think this will be considered as a serious security problem.  But if 
others do, it woudn't be difficult to make the signon viewer check to see if the 
database has been unlocked before displaying anything.
Clearing WON'T FIX resolution due to reopen.
Resolution: WONTFIX → ---
A couple comments:
1. The potential harm here is tremendous, because (a) it's relatively easy to 
guess/get another person's password, and (b) many people use the same password 
for different sites.  The contents of "Display Signon" make the former easier, 
and the latter very much a security problem.

So we do need to key the access to Display Signon.

2. Can we put all the signon info in clear text?  It'd (a) be more secure, and 
(b) easier to communicate the security to the end-user -- "all data is 
obscured/encrypted".

thx,
kevin
Surely you were joking when you said:

   " Can we put all the signon info in clear text?  It'd (a) be more secure,..."
oops.

Yes, meant to say, make all data "obscured".

thx,
kevin
OK, now I assume you are referring to the storage on the disk.  We can't make it 
all obscured for the following reason:

As the user surfs, whenever he arrives on a page containing a login form we need 
to be able to determine if we are already saving a login for that page.  And 
we need to do this before he has unlocked the database (otherwise he would be 
force do to unlock the database as soon as he starts browsing).  So we need to 
be able to get to the URLs of pages that we are saving.  That means that these 
URLs must be stored in clear text.  So now it is clear that we must maintain the 
data in two databases -- one in cleartext and the other obscured.  Furthermore, 
the field names must also be in cleartext since we match that up as well.  So 
all this goes into the cleartext file.

Now the values of the passwords certainly go into the obscured file.  That 
leaves just the usernames up for grabs.  I decided to put that in the clear file 
as well.  Don't recall if there was a technical reason for doing so or if it was 
done just so the signon viewer could work without the need to unlock the 
database (which I thought was a cool feature).

In any event, moving the username from the clear file to the obscured file at 
this time would be a non-trivial task.  However, disabling the signon viewer if 
the database is unlocked is simple.  So lets keep keep this bug focused on the 
signon-viewer issue since that is what was originally reported.

 
Regardless of what the bug originally reported, it did turn up the current 
important issue of clear-text user names.  I'd be happy to file a new bug if 
that's important.

Requiring the key to view "Display Signons" is good, but we need to obscure the 
usernames, too.  This is non-trivial work, as you mention, but essential, I 
believe, given all the js bugs/holes and the sensitivity of the usernames.  
Ideally, we know that we would want to be able to rely on the general security 
of the browser, but we also know that no one can confidently take this position, 
especially for beta1.

I suggest we obscure usernames to get the feature into Beta1.

thx,
kevin
Per discussions w/DP, let's make this change.

If database is unlocked and user chooses "Display Signons", user will be 
prompted for database key, which will then unlock the db and allow signon info 
to be displayed.

also, I'll file a separate bug (for post beta 1) for the obscuring of the user 
name info.

thx,
kevin
Assignee: kevinyen → morse
fixed
Status: NEW → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
verified as fixed on

linux, comm: 2000020209
winNT, non-comm: 2000020214
mac, non-comm: 2000020215
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.