User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:18.104.22.168) Gecko/20110420 SeaMonkey/2.0.14 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:22.214.171.124) Gecko/20110420 SeaMonkey/2.0.14 Form manager SOMETIMES stores credit card numbers and cryptogram codes entered on HTTPS: payment pages. This ALWAYS occurs on certain sites, not on others. The fields concerned MAY additionally have the attribute "autocomplete=off" (the former bug which stored fields of "type=password" appears to have been successfully fixed). Reproducible: Always Steps to Reproduce: 1. connect to the appropriate page of one of the payment sites concerned (of course this can only be done when actually making a payment!) 2. enter a credit card number and cryptogram (CV2) code 3. this data is stored and becomes visible in 'formhistory.sqlite' Actual Results: Form manager recorded secure data Expected Results: No form data entered on a secure page should be stored locally unencrypted. Verified up to SeaMonkey 2.0.14 (the indispensable extensions I use are not yet compatible with SeaMonkey 2.1) I will provide a recent list of the URL'S of 4 HTTPS sites (so far noted) and the field names concerned - on request by mail to any developer. Related bugs: 252486, 542986
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.
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.
(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)
> 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.
(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!
Created attachment 543505 [details] Screenshot. 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.)
(oops, forgot...) Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110626 Firefox/5.0 SeaMonkey/2.2
> 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.
Created attachment 543779 [details] Screenshot. 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.)
(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?
BTW, what other browsers are doing?
(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...
(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.
> 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.)
(In reply to comment #14) > > 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? Yes, that seems likely. > browser.formfill.saveHttpsForms;true That's the opposite of 'browser.formfill.disable_on_https=true'!!! (If both are specified, which takes priority? - the last read?) > Good thing Profiles generally aren't forward facing to the web? > http://www.filewatcher.com/_/?q=formhistory.sqlite The link is broken. Maybe Susan didn't want her files to be accessible on the web. (Sorry I don't understand your comment - read from France, here...) > (formhistory.sqlite is in no way "protected" by use of any Master Password, > so any access to the file can reveal its secrets.) Yes indeed. It was when examining a form history sqlite file opened directly that I first became aware of this security loophole. Otherwise, I would never have realised. Since, I have explored and found lots of interesting things in clients' history files - that they didn't even know were there themselves! Fortunately for them I advise them on security problems instead of exploiting their secrets. That's not the case for others - which is why I remain intransigent on these security problems.
http vs. https seems like much to coarse a decision criteria. I'm planning to force all of my websites to https in the next iteration - there are several reasons to do so that do not involve the page content data. That certainly doesn't mean I want all of my sites' forms to have autocomplete disabled, though. Some people absolutely do use HTTPS to protect form data but that does that mean that every use of HTTPS is to protect form data, so it's not good decision criteria. I agree with the part about not storing that data unencrypted, though. Wallet systems integration would be helpful here - I use that in chromium even though I use encrypted filesystems, just in case something gets read access to my $HOME. Mac and Linux systems at least have those built in. I don't know about Windows. Using autocomplete=no for the saving criteria would be a good compromise. I use the Always Remember Password extension to defeat those, but that's my personal, conscious security decision and remains an option for those who want the behavior.
Given that the industry is pushing everyone to HTTPS, I don't think we'd want to do this. See also bug 1361220.