Bugzilla

Comment 1

•

13 years ago

I do not think we shouldn't save data in HTTPS. That means not saving your twitter account name nor your facebook account name if you are using those services through HTTPS (which you should do for security reasons).
The issue you point is related to saving credit card information and authors should mark fields with credit card with autocomplete="off". In addition, if I remember correctly, the form manager doesn't save a field if it looks like a credit card number. I think this is on Gecko 1.9.2 or 2.0 and this bug has been filed with Gecko 1.9.1. That might be the explanation.

OS: Windows XP → All

Hardware: x86 → All

Comment 2

•

13 years ago

I confirm it should not happen since at least Gecko 2.0:
https://mxr.mozilla.org/mozilla-central/source/toolkit/components/satchel/formSubmitListener.js#69

Moving back to SeaMonkey component.

Component: Form Manager → Autocomplete

Product: Toolkit → SeaMonkey

QA Contact: form.manager → autocomplete

Version: 2.0 Branch → unspecified

Reporter

Comment 3

•

13 years ago

(In reply to comment #1)
> I do not think we shouldn't save data in HTTPS. That means not saving your
> twitter account name nor your facebook account name 

That is not a sufficient reason to justify the risk. Others also have remarked (for the other related bugs) that
 - if autocomplete causes a security problem, they don't need it
 - it makes the autocomplete feature unuseable - so they turn it off altogether

One possibility would be a personal whitelist of HTTPS sites for which secure data may be stored.
Another possibility - if you are lazy and want secure data to appear without typing it - is to use keyboard macros.

Informed users must knowingly accept such risks: those who don't know that the risk exists nor how to avoid it should not be exposed.

> if you are using those services through HTTPS (which you should do for security reasons)

You recommend using HTTPS for security reasons - but you want security to be disabled!!!
(Why bother hiding passwords...?)

> The issue you point is related to saving credit card information and authors
> should mark fields with credit card with autocomplete="off".

One CANNOT and MUST NOT count on all authors using a non-standard feature to ensure users' security.
"autocomplete" is an invalid attribute which causes validation failure  (for HTML 4.01 Strict - even Transitional - and XHTML)

Philip Chee

Comment 4

•

13 years ago

> I confirm it should not happen since at least Gecko 2.0:
> https://mxr.mozilla.org/mozilla-central/source/toolkit/components/satchel/formSubmitListener.js#69

SeaMonkey 2.1 corresponds to Gecko 2.0.1 (Firefox 4.0.1) so this should be fixed now.
Chris, please retest with the current version of SeaMonkey (2.1). Credit Card numbers, SSNs etc should not be stored.

Reporter

Comment 5

•

13 years ago

(In reply to comment #4)
>
> SeaMonkey 2.1 corresponds to Gecko 2.0.1 (Firefox 4.0.1) so this should be
> fixed now.
> Chris, please retest with the current version of SeaMonkey (2.1).

OK, Philip, thanks.
I will test ASAP - but I won't have all the results immediately: most of these payment pages are only accessible when you're actually ...paying. So I have to wait for the next bills!

Comment 6

•

13 years ago

Attached image Screenshot. — Details

All of the data fields; Phone, Contact, Card Number, Cardholder Name, & Charge Amount /were/ populated by way of Form Manager.

(Group # is pre-populated by Carefirst.)

I'm not complaining, I actually like the "feature".

But if the intent is that it should not display said data, it looks like it still does.

(I checked this with an existing Profile, rather then with a new, clean Profile.)

Comment 7

•

13 years ago

(oops, forgot...)

Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110626 Firefox/5.0 SeaMonkey/2.2

Reporter

Comment 8

•

13 years ago

> All of the data fields; Phone, Contact, Card Number, Cardholder Name, &
> Charge Amount /were/ populated by way of Form Manager.

The check that Mounir referred to ("...looks like a credit card number") is a Luhn algorithm test, which validates 16 (or 15???) digit credit card numbers using their incorporated checksum (the last digit) - but will not recognise any other numbers (telephone etc... - except portable telephone IMEI codes - and I think some sort of American social security numbers as well, but I am not familiar with that).
So in general _only_ credit card numbers are concerned and excluded, and _only_ if they pass the test (normally they should). You could check your number on my site to see if it is considered valid according to the same criterion - 'Programmes' -> 'Outils en ligne' -> 'Outil pour vérifier la validité d'un numéro de Carte Bleue'.
 - if your number is 'probably valid' then according to the 'satchel' code it shouldn't be recorded and there is therefore still a problem in this respect with this module.
 - if it isn't considered valid then it is normal if the code displayed doesn't react. It is also normal that this code doesn't block the other data you described.
HOWEVER that doesn't change the fundamental problem: that NO data entered on an https: site should be recorded (unencrypted or in such a way that it can be automatically re-entered without a password) without the EXPLICIT consent of the user. 
The design of this form manager appears to still be seriously insecure and it should therefore be totally disabled, using an alternative until the problem is finally fixed.

Comment 9

•

13 years ago

Attached image Screenshot. — Details

Starting with a (cleaner) Profile (where Carefirst had never before been visited), all the data fields /except/ the creditcard number are retained.

Two instances of cardHolderName, contactName, & phoneNumber, & (the single) charge1, were entered new & retained.  The creditcard number, though valid, was not retained.
 
 
(Strange monkey that about:data & how & where Form Data are displayed.)
(Now I won't comment on Session Restore restoring https: sessions as I'm sure a bug exists for that, heh.)

Comment 10

•

13 years ago

(In reply to comment #8)
> HOWEVER that doesn't change the fundamental problem: that NO data entered on
> an https: site should be recorded (unencrypted or in such a way that it can
> be automatically re-entered without a password) without the EXPLICIT consent
> of the user. 
> The design of this form manager appears to still be seriously insecure and
> it should therefore be totally disabled, using an alternative until the
> problem is finally fixed.

So, using HTTPS and saving data might be an issue for some users, I agree. Though, some users might just not care because they do not consider a username or a phone number to be highly sensitive. I see a few options here:
1. We can consider that users who really don't want these informations to be saved will be using a Master Password to protect them and we do nothing;
2. Don't save form data from HTTPS website unless there is a Master Password;
3. Add an option in about:config to make 2 the default.

I would tend to think 1 is enough. Are you using a Master Password? Why do you think saving those data is harmful? Why saving a password in clear text is worse than the behavior you describe?

Severity: critical → normal

Status: UNCONFIRMED → NEW

Component: Autocomplete → Form Manager

Ever confirmed: true

Product: SeaMonkey → Toolkit

QA Contact: autocomplete → form.manager

Summary: Form manager records secure data → Considering not saving form data when using HTTPS

Version: unspecified → Trunk

Comment 11

•

13 years ago

BTW, what other browsers are doing?

Reporter

Comment 12

•

13 years ago

(In reply to comment #10)
> 
> So, using HTTPS and saving data might be an issue for some users, I agree.
> Though, some users might just not care because they do not consider a
> username or a phone number to be highly sensitive.

Some users don't care because they think they are the only person who has access to their computer...
 - but the grandson and his friends who come to visit and just use it to play games are often cleverer than them...
 - and then maybe one day it breaks down and the technician who fixes it can read and note all their secrets.

Other users don't care because it isn't their personal risk. It's a nightmare when you administer a network and confidential data is stored on users computers - you don't know everything they do, and - when there is a security bug like this - they don't even know themselves.

> I see a few options here:
> 1. We can consider that users who really don't want these informations to be
> saved will be using a Master Password to protect them and we do nothing;

??? There are various 'master passwords' on all my machines but none of them stop SeaMonkey from recording data that it shouldn't. What do you mean by a Master Password?
 - I have a BIOS password and a Windows password. That makes it difficult for someone who just passes by to start my computers (if I am stupid enough to leave them running when I'm not there...). But anyone who knows how can get round that (just like I can when a client loses his own).
 - I have a 'Master Password' in SeaMonkey. But it isn't required to fill in forms with the existing Form Manager...

> 2. Don't save form data from HTTPS website unless there is a Master Password

 ...so yes, it could be made necessary. Even with any reasonably secure simpler password (my Master Password has more than 32 mixed characters and that level of protection isn't usually necessary for a lot of data).

> 3. Add an option in about:config to make 2 the default.

The existing option 'browser.formfill.disable_on_https' should be the default and only users who are aware of the risks (and approved by their network admins) should (be allowed to) change it.
That means that any risk should be 'opt in'.

> I would tend to think 1 is enough. Are you using a Master Password? Why do
> you think saving those data is harmful? Why saving a password in clear text
> is worse than the behavior you describe?

I think I already answered most points above.
 - yes I have several passwords which protect access at different levels.
 - saving _any_ secure data is harmful if any person who has access to your computer (even for a few minutes) and who shouldn't know it can use it, for example to log in to a restricted account or fill in a form - to purchase something, or consult or change private information... 
Saving a password in clear text is like removing all restrictions on access! Even a reasonably competent user (without being an engineer or hacker) can do things in your place for which you wouldn't dream of leaving instructions written on a piece of paper lying around on your office desk...

Severity: normal → critical

Summary: Considering not saving form data when using HTTPS → Form data should not be saved when using HTTPS

Reporter

Comment 13

•

13 years ago

(In reply to comment #9)
>  
> Starting with a (cleaner) Profile (where Carefirst had never before been
> visited), all the data fields /except/ the creditcard number are retained.

OK, so the credit card number was probably excluded by the Luhn algorithm test.

Now, have you set your 'browser.formfill.disable_on_https=true'? - which _should_ prevent saving all the other data.
 - if yes, then there is still a bug
 - if no, then it is probably working as programmed - BUT that should be the default option and nobody should need to change it unless they are aware of the risks.

Comment 14

•

13 years ago

> so the credit card number was probably excluded by the Luhn algorithm test

Yes, it looks that way.
With the existing Profile, I suppose it was just a holdover from a time when the [input] check did not exist & was never since purged?

> Now, have you set your 'browser.formfill.disable_on_https=true'?

browser.formfill.saveHttpsForms;true

Good thing Profiles generally aren't forward facing to the web?
http://www.filewatcher.com/_/?q=formhistory.sqlite

(formhistory.sqlite is in no way "protected" by use of any Master Password, so any access to the file can reveal its secrets.)