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)
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
Assignee | ||
Comment 1•25 years ago
|
||
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
Assignee | ||
Comment 3•25 years ago
|
||
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
Assignee | ||
Comment 5•25 years ago
|
||
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
Assignee | ||
Comment 8•25 years ago
|
||
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
Assignee | ||
Comment 10•25 years ago
|
||
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.
Reporter | ||
Comment 11•25 years ago
|
||
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
Reporter | ||
Comment 12•25 years ago
|
||
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
Assignee | ||
Comment 13•25 years ago
|
||
fixed
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Comment 14•25 years ago
|
||
verified as fixed on linux, comm: 2000020209 winNT, non-comm: 2000020214 mac, non-comm: 2000020215
Status: RESOLVED → VERIFIED
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•