Closed Bug 542008 Opened 12 years ago Closed 12 years ago

Passwords recorded with form data

Categories

(Toolkit :: Form Manager, defect)

1.9.1 Branch
x86
Windows XP
defect
Not set
critical

Tracking

()

VERIFIED INCOMPLETE

People

(Reporter: bitwise, Unassigned)

Details

(Whiteboard: [sg:low local])

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.5) Gecko/20091102 Firefox/3.5.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.5) Gecko/20091102 Firefox/3.5.5

Using an SQlite editor to examine 'formhistory.sqlite' I found 2 passwords recorded.
1. I can certify that these passwords were _never_ typed in non-password fields (I would have seen them in clear...). I am the only user and only I know them.
2. I do know however that these 2 passwords had been tried incorrectly on certain login pages - so I will try to find them again (many use the same of one, less of the other...) and reproduce the problem.
So this is an initial urgent pre-report - I will try to provide more precise details asap.
Regards


Reproducible: Sometimes
Version: unspecified → SeaMonkey 2.0 Branch
Whiteboard: [sg:low local]
The form saving code is fairly strict:

http://mxr.mozilla.org/mozilla-central/source/toolkit/components/satchel/src/nsStorageFormHistory.cpp#389

If the input's type is not "text", it's not saved. Password fields are type="password", and are thus never saved.

I think it's more likely that you either mistyped these somewhere, or the page itself was doing odd things with copying values to other inputs / changing types dynamically. Or that these values came from the old SeaMonkey wallet code, and were imported into Satchel when you upgraded.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → INCOMPLETE
As confirmed by other users, 'password' fields are indeed sometimes saved.
I have since also checked this on several clients' computers.

No, I have certainly _never typed a password in the wrong field.
I have userChrome.css and userContent.css personnalised so that:
 - on 'https:' pages the URL bar turns red
 - 'password' fields are displayed in red (red dots, that is).
Impossible to not notice a mistake.

No sensitive values were imported from an older version: I know exactly what had been recorded previously - directly via the late form manager.

I strongly recommend disabling the new autocomplete function (which is dangerous) completely and definitively, and installing 'Autofill forms', kindly ported by Phip CHEE.
http://xsidebar.mozdev.org/modifiedmisc.html#autofillforms

Regards
Status: RESOLVED → VERIFIED
Resolution: INCOMPLETE → WONTFIX
(In reply to comment #2)
> As confirmed by other users, 'password' fields are indeed sometimes saved.
> I have since also checked this on several clients' computers.

Which users? What sites?

This would most definitely be a bug if it happens, but I don't see how it's possible from the code. So, we need further information and/or a testcase to understand what's happening.
Status: VERIFIED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: WONTFIX → INCOMPLETE
(In reply to comment #3)

> Which users?

Mostly users of FireFox (same problem - but more numerous than those of SeaMonkey) - naturally I am not going to name them publicly.

> What sites?

That is more difficult, because it requires constant tracking to determine which sites (which I am now doing daily).
For a start I was able to login to a customer's MSN account the other day using data stored by FireFox.
I have also found bank card numbers, complete with date and CCV code - but I can only see the field names: which don't suffice to identify the site (one needs to return and see what each site labels its form fields).

> This would most definitely be a bug if it happens, but I don't see how it's
> possible from the code.

It isn't because you can't see it from looking at the code that it doesn't happen!!!  If this was the case no bugged software would ever be released!

> So, we need further information and/or a testcase to understand what's happening.

Start with:

Bug 542986 - VERIFIED DUPLICATE of bug 252486

NEW [good first bug]  Bug 252486 -  Option to disable form manager (saved form information) for secure websites (https)  

Regards
Status: RESOLVED → VERIFIED
Resolution: INCOMPLETE → WONTFIX
This bug is INCOMPLETE, not WONTFIX.

WONTFIX means a patch would not be accepted, which clearly isn't the case here

(In reply to comment #4)

> Mostly users of FireFox (same problem - but more numerous than those of
> SeaMonkey) - naturally I am not going to name them publicly.

Uhm, ok. Well, let them know about this bug number at least?

> > What sites?
> 
> That is more difficult

If satchel is storing a password for a site, then you should know what site that password is for, no? Unless you're using the same password on multiple sites, which is a bad idea. ;-)

> For a start I was able to login to a customer's MSN account the other day using
> data stored by FireFox.

What data? Saved form data, password, or cookies? It would be best to keep separate issues in separate bugs -- file a new bug?

> I have also found bank card numbers, complete with date and CCV code 

None of those are passwords. Covered separately by bug 188285.


> > So, we need further information and/or a testcase to understand what's happening.
> 
> Start with:
> 
> Bug 542986 - VERIFIED DUPLICATE of bug 252486

Neither of these bugs has additional information or a testcase.
Status: VERIFIED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: WONTFIX → INCOMPLETE
Group: core-security
Component: Security → Form Manager
Product: SeaMonkey → Toolkit
QA Contact: seamonkey → form.manager
Version: SeaMonkey 2.0 Branch → unspecified
Chris, can you share some more information about the tool you're using you detect this bug?  Is it clever enough to recognize what "looks like" a password or matches something in the password database, making it easy to run?

Maybe if I could find an example in my own form history, I could guess at steps to reproduce.
(In reply to comment #5)
> This bug is INCOMPLETE, not WONTFIX.
> 
> WONTFIX means a patch would not be accepted, which clearly isn't the case here

OK - so it has been VERIFIED but despite many alerts nobody seems to want to accept that it is imperative to FIX it.

> Uhm, ok. Well, let them know about this bug number at least?

Sure - I have already broadcast a warning about this bug to all my clients as well as on Usenet.

> If satchel is storing a password for a site, then you should know what site
> that password is for, no? Unless you're using the same password on multiple
> sites, which is a bad idea. ;-)

Maybe it's a bad idea - in principle I agree, but in practice I have dozens of sites requiring passwords and for those which aren't very important of course I use the same password (you think anyone can remember different passwords for 50 different e-merchants?). Only for those which are particularly sensitive I give a special password (the most secure don't even allow you to choose a password, it is allocated by the server).

> > For a start I was able to login to a customer's MSN account the other day using
> > data stored by FireFox.

> What data? Saved form data, password, or cookies?

Saved form data - which included the password (despite 'autocomplete="off"').
Where is this documenented?  For HTML 4.01 Transitional (still very widely used) it is defined as 'reserved for future use' - so not much use counting on it - even if it occurs to the site programmer to include it.

> It would be best to keep  separate issues in separate bugs -- file a new bug?

I filed a bug and it was reported as a duplicate.

> > I have also found bank card numbers, complete with date and CCV code 
> 
> None of those are passwords. Covered separately by bug 188285.

A serious parallel probleme of security, though.

> Neither of these bugs has additional information or a testcase.

But many confirmations.
Status: RESOLVED → VERIFIED
Component: Form Manager → Security
Product: Toolkit → SeaMonkey
Resolution: INCOMPLETE → DUPLICATE
Version: unspecified → SeaMonkey 2.0 Branch
Duplicate of bug: 252486
Hi Jesse

(In reply to comment #6)
> Chris, can you share some more information about the tool you're using you
> detect this bug?  Is it clever enough to recognize what "looks like" a password or matches something in the password database, making it easy to run?

I started by using an SQlite editor simply to examine the contents of the new 'formhistory.sqlite' - just by curiosity.
I was shocked to find two passwords (known only to myself) and a bank card number (with all its details - date and CVV - but fortunately a virtual e-card because I never use anything else) recorded unencrypted (so readable with a hex or even text editor).
Since then I have disabled autocompletion ('Historique des formulaires' in French) and installed 'Autofill forms' recently ported by Philip CHEE.

> Maybe if I could find an example in my own form history, I could guess at steps to reproduce.

Now I am sure of my own security I will re-enable autocompletion (for my own computer alone) and survey the data recorded daily to try to reproduce a test case.
But it doesn't happen that often.

I can already tell you that certain fields concerned were labelled
"bibit_card_number" and
"bibit_card_control_number"
and for password fields just normally
"name=password" "type=password" 
- but I have no means to identify the site other than waiting for it to happen again (I've tried and I'm watching...).
However there is absolutely no reason to assume that any site programmer should automatically think to use 'autocomplete"=off"' (stupid reason) - nor that all navigators should understand this attrubute nor respect it.  'type="password"' should be enough.
(If you don't agree please provide references - including for older versions of HTML - for example 'Transitional 4.01' still very widely used - and of earlier navigators that understand this new 'directive'. In my documentation for this version it is 'reserved for future use' (and a verification fails).

Regards
Christophe
NOT a dupe of that bug; The issue you DESCRIBE here is actual PASSWORDS for a field labeled as type="password" ending up in form manager.

The data to support such a bug has been asked, asked, asked, and asked. with only a "BAD BUG FIX ME".

Without such data we can't fix it. The code itself that does the storing indicates that there IS NO bug with this type of cause.

Please, provide us with the information or testcase we need to actually solve this issue. And leave the resolution of the bug alone when you don't [seem to] know what each value actually means.
Component: Security → Form Manager
Product: SeaMonkey → Toolkit
Resolution: DUPLICATE → INCOMPLETE
Version: SeaMonkey 2.0 Branch → 1.9.1 Branch
You need to log in before you can comment on or make changes to this bug.