Closed Bug 188285 Opened 22 years ago Closed 15 years ago

Form autocomplete should not store credit card numbers

Categories

(Toolkit :: Form Manager, defect)

Product:
Toolkit
Component:
Form Manager
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9.3a4

People

(Reporter: m1scha_m, Assigned: jdm)

References

(Depends on 1 open bug)

Details

(Keywords: privacy, Whiteboard: [sg:want?][good first bug])

Attachments

(4 files, 6 obsolete files)

"Remember this form data?" bar mockup
43.28 KB, image/png
Details
Proof of concept method for exploiting Firefox's saving of CC numbers
5.42 KB, text/html
Details
Script to generate Luhn-satisfying numbers
605 bytes, text/plain
Details
Patch with many more tests
13.30 KB, patch
Dolske
: review+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.3a) Gecko/20030105 Phoenix/0.5 Build Identifier: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.3a) Gecko/20030105 Phoenix/0.5 Form autocomplete collects a lot of information, including credit card details. All that is needed to access this information is to enter the first number/letter of the sequence. This can be done by anyone who uses the computer, not just the owner/regular user of the machine. To avoid 'giving away' this type of informatiom, form autocomplete should either be more dicreet, or not record this type of information. Reproducible: Always Steps to Reproduce: 1. 2. 3. Expected Results: Not display/record credit card details.
Phoenix could avoid storing strings in form autocomplete when: 1. The string contains only digits, spaces, and hyphens. (This would also catch US social security numbers, bug numbers, and sometimes telephone numbers.) 2. The string contains only digits, spaces, and hyphens, contains 16 or more digits, and the first 16 digits validate against a public credit card number validation algorithm. (Most 16-digit strings are not valid credit card numbers.) See also bug 46590, "insecure submit of credit card # should warn user even if insecure submit warning turned off".
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Form autocomplete should not store credit card details, or similar information → Form autocomplete should not store credit card numbers
Could we use PSM to encrypt from data, like we do for login/password information? If the user has encrypted his form data, we can assume it is the user and not someone else on the computer.
I have a similar occurance: when I go to my online banking log-in page, my card number and password are already there (!!). I've tried removing every trace of my bank from Phoenix (cache, cookies...) and Mozilla, but still no luck. Am I going insane or is this a serious bug? Using: WinXP/Pheonix0.5
form completion can be disabled or if enabled, data can be deleted in preferences.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
verified.
Status: RESOLVED → VERIFIED
*** Bug 207479 has been marked as a duplicate of this bug. ***
*** Bug 231681 has been marked as a duplicate of this bug. ***
Asa: I disagree with your reasons for wontfixing this bug. Storing credit card numbers by default means that a virus could collect credit card numbers easily. Most users won't turn off form autocomplete (either because they don't think of the security risk or because they like using the feature for less sensitive data). Nobody will remember to delete their credit card number from autocomplete every time they enter it.
*** Bug 243425 has been marked as a duplicate of this bug. ***
I agree with Jesse. It is silly and ignorant to claim this is a WONTFIX. Why should I have to disable a very helpful feature of my web browser in order for it to be secure?! Is the reasoning for setting this as WONTFIX simply because IE also has this problem? Are we not building the most useful and secure web browser? If so, FIX THIS BUG! If not, why should I use Firefox? I'm not just blowing steam. I represent a large number of Internet users who want a good browser that keeps my sensitive information secure.
Actually IE doesn't have this bug because it does look for input name="CC" or some form of CC number and just doesn't bother storing them.
*** Bug 258031 has been marked as a duplicate of this bug. ***
See also bug 257455, "Form information shouldn't be saved on HTTPS sites".
> Storing credit card numbers by default means that a virus could collect > credit card numbers easily. They can do that anyways, by installing a keyboard sniffer and waiting for you to enter it the next time. There is actually malware like that in the wild. In that case, autocomplete is actually minimally *more* "secure", because you don't have to type it and thus generic keyboard sniffers have less chances to catch it. IMHO, if you don't trust your computer, don't use it for handling sensitive data. If you do trust your computer, no problem saving the data.
Is it possible to have a security tab? A tab that collects nothing. It has the same security as any other Mozilla/Firebird page, but allows users who would normally want information collected, to visit a page and feel secure their private details were not being recorded. If it could be done I would like to see Microsoft etc try to top it.
(In reply to comment #14) > > Storing credit card numbers by default means that a virus could collect > > credit card numbers easily. > > They can do that anyways, by installing a keyboard sniffer and waiting for you > to enter it the next time. There is actually malware like that in the wild. In > that case, autocomplete is actually minimally *more* "secure", because you don't > have to type it and thus generic keyboard sniffers have less chances to catch it. > > IMHO, if you don't trust your computer, don't use it for handling sensitive > data. If you do trust your computer, no problem saving the data. There's a huge difference between a sniffer and a new virus though. If you get a sniffer installed changes are your AV will detect and kill it before your next purchase... whilst if the credit card numbers or stored a new virus can simply target the auto-complete file and transmit it to wherever it likes before AV has its virus definitions updated. Storing numbers is a massive leap into poor security.
*** Bug 258364 has been marked as a duplicate of this bug. ***
*** Bug 262705 has been marked as a duplicate of this bug. ***
*** Bug 271203 has been marked as a duplicate of this bug. ***
It ought to be pretty clear from the number of duplicate filings of this bug that users view it as a serious issue. The objection to fixing it based on viruses ignores the fact that many users take steps to secure their systems against viruses. The objection based on whether or not the user trusts their computer ignores the possibility of robbery of notebooks. It looks to me from reading the comments that there are a number of ways that this problem could be fixed, or at least minimized, fairly simply, the cc catch, number of digits, etc. As a retired software engineer with some 40 years of working history, it annoys me when too many engineers, out of apparent arrogance, ignore serious interface issues which trap unwary users. It's unprofessional behavior, not ready for prime time.
I'd have to agree whole-heartedly with Karen. Why aren't you going to fix this problem? If someone else uses my computer, the first cc input box they see is going to bring up my credit card number. They just have to subtly write it down, and they've got all the porn they want, courtesy of my bank account. There is NO need for credit card numbers to be stored in autocomplete. And what's this about keyloggers? I lock my car every night, even though carjackers may rob me at gunpoint. And don't mention multiple accounts and turning off autocomplete, 95% of the population doesn't do this. Someone will get burnt by this one day. Most people don't know about "security"/"trust" issues around computers. It really needs to be fixed.
Calm down everyone. This isn't the first bug where the Mozilla team has failed to take action on an important bug. That's just how they are. You'll get used to it after 6 exasperating years.
*** Bug 277113 has been marked as a duplicate of this bug. ***
This absolutely should get attention. If one of the defining features of Firefox is that it is a more secure way to browse the web, then this needs to be taken care of (especially if IE doesn't store cc numbers in autocomplete). Flat out refusal to create a workaround that will provide a tangible security benefit is just short sighted and arrogant.
I was told by another user that this was fixed in the most recent Firefox release, even if you install with a fresh profile. Can anyone confirm or deny this?
OK, I'm not a coder so writing a full test page isn't going to be easy. BUT I've got a scenario that might be worth considering. The way the form fill in seems to work is that every time its sees a form item called XyX it fills in data foo. Regardless of location (IP number location not physical) So if I go to Foo.com and enter a Credit Card, then go to Bar.com and it has a form item named the same ... the card number will occasionally appear. (This I've seen and was part of the original point on this bug against FF (since merged here) on Linux) Now picture this. Going to a phised site like a login for New York Times. You enter your user name and password. This gets passed on to the real NYT site and you see your article. Unknow to you is the fact that there were multiple hidden form items on this phished page. Each one grabbing or trying to grab personal data CC numbers. SSN's. ID numbers Bank Numbers any of a number of things the use shouldn't allow to be "retained" but can under the current system. Add to this the fun you can have with ActiveX and windows and it should be pretty easy to get some very sensative data. No virus needed. Heck distribute in some of the page counter code what is needed ... you can have it piping you data from hundereds of locations. People blindly installing your little jscript counter on their AOL or RoadRunner Webpage. I have found a work around.. Turn off XUL.Cache Turn off Disk Cache Turn off Ram Cache Turn off form data saving. I take a performace hit of minor proportion. But I'm getting safer.
So, I'm very ignorant here, but saving and checking the IP address would prevent the phishing problem, wouldn't it? I have to say the phishing scenario just presented scares me a lot more than the original problem. Also, with all this too much saving, I wonder why Firefox doesn't remember my yahoo groups username and password?
It seems to me the answer here is fairly simple: the form should be using AUTOCOMPLETE="off". If it isn't, that's a security hole placed there by the webpage designer. Any heuristic Firefox could use is bound to have false positives and negatives, neither of which is desirable.
So, you are saying millions of web developers should change what they are doing, and use invalid proprietary HTML, so that a single browser can continue to store credit card numbers in plaintext while everyone else has fixed the problem (AFAIK)?
No, that's not what he's saying. He's saying that it's better to always store credit card numbers in plain text and even helpfully display them as a popup on some forms than it is to make any attempt at not doing this (like not caching form data from SSL pages).
Of course, this bug now makes Firefox look as stupid as IE when it comes to security. Notice the security issue where it is possible to steal credit card numbers from autocomplete popups even if the user doesn't select that number. Of course, just like MS, did Mozilla fix the core issue? No. They band-aided it. See http://www.mozilla.org/security/announce/mfsa2005-19.html
*** Bug 287274 has been marked as a duplicate of this bug. ***
Why is this a wontfix? It makes Firefox less secure than IE in a very obvious way. It really is quite embarrasing; if the media got hold of it it could undo a lot of the hard work of the spreadfirefox team.
(In reply to comment #28) > It seems to me the answer here is fairly simple: the form should be using > AUTOCOMPLETE="off". If it isn't, that's a security hole placed there by the > webpage designer. Any heuristic Firefox could use is bound to have false positives > and negatives, neither of which is desirable. I can tell you that I've never heard of the AUTOCOMPLETE attribute for forms, and I've been making web pages for a long time. So I'm guessing a few other web designers haven't heard about it either (or don't use it because it's invalid), and thus there's a problem.
Well, the bug is self-explanatory i think. But here's a visual demonstration.
If you are currently paranoid you got two solutions: Turn off Form History, use an extension that clears that easily (got several: prefbar, X, ....) or try teh form histor extension at https://addons.mozilla.org/extensions/moreinfo.php?id=1090
> To find out my card number, you just need the first digit. You don't even need the first digit. Just focus the textbox and press the down arrow key, or double-click the textbox, when the textbox is empty.
Telling people to turn off form history, is a bit like saying you don't need form history or auto complete. That we don't care, and there's nothing you can do to make us care. I might make the same or similar searches over a few days, then I use shift delete to get rid of them. I don't want to clear everything out just for the sake of a few numbers. If this is a WONTFIX because it can't be fixed, then people should be warned. As it is there's 37 replies here, so very people know about it. But if some start losing their money because of it, you don't think they're going to kick up a stink.
*** Bug 269098 has been marked as a duplicate of this bug. ***
I am agree for 100%. When I have noticed that my CC number is saved - I turned off that future in privacy options, but I AM NOT GLAD because of that. IT IS like saying you don't need form history or auto complete at all. I need it but not for sensitive data, I am disapointed because of that. From my point of view it is worth to consider to ask for permission before Firefox save form data instsead of general yes or no checklist in privacy option.(In reply to comment #38) > Telling people to turn off form history, is a bit like saying you don't need > form history or auto complete. That we don't care, and there's nothing you can > do to make us care. > > I might make the same or similar searches over a few days, then I use shift > delete to get rid of them. I don't want to clear everything out just for the > sake of a few numbers. > > If this is a WONTFIX because it can't be fixed, then people should be warned. As > it is there's 37 replies here, so very people know about it. But if some start > losing their money because of it, you don't think they're going to kick up a stink. I am agree for 100%. When I have noticed that my CC number is saved - I turned off that future in privacy options, but I AM NOT GLAD because of that. IT IS like saying you don't need form history or auto complete at all. I need it but not for sensitive data, I am disapointed because of that. From my point of view it is worth to consider to ask for permission before Firefox save form data (like during password saving) instsead of general yes or no checklist in privacy option. It is quite easy to get saved CC number later on by another person. IT IS A SERIOUS ISSUE. You should reopen bug and fix it.
*** Bug 320199 has been marked as a duplicate of this bug. ***
Before I even do anything, are any patches to this bug going to be ignored? I can make a Javascript that at least tests for well-known credit card numbers (like Visa, MasterCard, Diners, AmEx, etc.) and uses a LUN check to see if it really is a credit card number, but I'm not even going to bother if no one is going to take the trouble to do anything about it afterwards. And, if the position is that this will not be fixed, even with a parch in hand, please explain why.
Registration pages requiring credit card info and other sensitive info are usually HTTPS (supposedly secure) pages. FireFox's reputation rides on the back of IE's numerous security problems. All FireFox need do really is turn off AutoComplete for HTTPS pages. I think that's a reasonable request, nay, Demand. Suggestions that users should know better and Clear Private Data (FF1.5) manually every time (and so also clear other info they may want autocompleted) is ignorant of good security practice. Don't assume users are Geeks and know of the problem and how to clear it, even when it's easy to get at. The information is stored somewhere, say the Windows registry, and might be retrieved by a hacker, a virus, hacker, scriptkiddie or the like. Passwords aren't autocompleted for good reason, neither should HTTPS forms, it is reasonable to assume the information on Secure pages is sensitive.
Credit card numbers are immeasurably worse in the hands of attackers than passwords. Passwords gain access to that particular resource protected by the password. Credit card numbers have the potential to empty my bank account, bounce rent and utility checks, and destroy my credit in a matter of days.
Component: Location Bar and Autocomplete → Form Manager
Unfortunately, the problem is not limited to credit-card numbers. What about banking PINs, passwords, etc. etc.? You can't trust secure sites to turn off autocompletion. The browser is the only other choice. Just reopen bug 190700.
Component: Form Manager → Location Bar and Autocomplete
Component: Location Bar and Autocomplete → Form Manager
There should be provision on the menu bar, say under Tools, to allow the user to turn something off or on, when visiting a site where they do not wish information to be stored. This puts the onus back onto the user. It also allows the user to be selective in other areas, where they may also not wish information to be stored. If you can turn remembering information off under Options > Privacy, surely it is also possible to add that switch closer to the main page. Perhaps even on the main page, for those who can't remember what day it is. It can only enhance Firefox's reputation.
You don't need to trust sites to turn off autocompletion. We already have a a condition which alerts us to the presence of sensitive data - SSL. When SSL was implemented it was realized that data sent over SSL was generally of a more sensitive nature and it was not cached to avoid placing sensitive data in the open in the disk cache, thereby creating a security risk. This autocomplete "feature" is simply a subset of page caching (by caching user-initated states). Mozilla should do the same thing and not cache form data from SSL pages. As far as sensitive information entered onto non-SSL pages, I think it's fair to assume that one is not concerned with security if they are submitting data to a Web site without SSL. However, even this can be addressed by having Firefox ask before it saves form field data. All of this is moot since it is verified "wontfix." For those concerned about security the feature is switched off entirely, and those that do not care about the security of their form data have it on.
Jerry, your comment belongs on bug 190700, so I replied there.
OS: Windows 98 → All
Hardware: PC → All
Product: Firefox → Toolkit
Note that the website itself can prevent auto-completion for the fields that don't need it, see <http://www.whatwg.org/specs/web-forms/current-work/#the-autocomplete>
Responding to comment #51, I don't think that you should rely exclusively on web site designers to enforce security. There are way, way too many examples of poor site design, as any competent hacker knows. I also don't think that you should "expect" the average user to notice or reconfigure FireFox to not save credit card info. It is the responsibility of FireFox designers, if they want to have the world's best browser, to build in sufficient security safeguards. I'm not going to try to design this fix. The "market requirement" (speaking as a product manager) is to not store or autocomplete social security numbers, PINs, and credit card numbers. And as a fix, provide a "1 click" function that cleans out such information from FireFox's cache.
(sorry for the bug spam) It's very simple : if you don't want your credit card number to be stored in the auto-complete cache, then you should switch off the entire autocompletion cache (Tools->Options->Privacy->remember what I enter ...). Even with server side help (autocomplete="off") or with a clever algorithm that tries to recognize a credit card number (can't be made fool-proof), there's still the possibility that it's stored by accident. Or that you can find it in your webcache, or in the history list or whatever. If you want privacy, then all such caches should be disabled. In the forthcoming Firefox 3.1, there's a private browser mode, which temporarily switches off all caching. Or where you can remove all traces of the last hour or day, if you discover after-the-fact that you should have used private browsing mode. That the solution the Firefox designers have built.
(In reply to comment #53) > or with a clever algorithm that tries to recognize a credit card number The implication here is that it is difficult to recognize a credit card number when, in fact, it is not difficult at all. All credit cards begin with a distinguishing number depending on the issuing bank, and they all match the Luhn algorithm which is very easy to implement. The same holds true for SSNs. There aren't too many common 9-digit numbers in a 3-2-4 sequence.
Not all credit or debit cards use ISO 7812 numbers. My old debit card for instance does not validate (recently a ISO 7812 number was added to correct this, but it still carries the old number too). But that's not the point. Where do you stop ? You also need to protect other private data : bank account numbers (various schemes), PIN codes (looks like any 4-digit number), passwords, identity card numbers, passport numbers, ... I'm Belgian, so a SSN doesn't work for me, but the equivalent here is a 6-3-2 number.
(In reply to comment #55) > But that's not the point. Where do you stop ? There are two arguments inherent in your position. 1) "if we can't protect ALL private data, then we shouldn't protect any," and 2) "we shouldn't add privacy/security features unless somebody can make a convincing argument that we should." If these are the rationale behind Mozilla Corporation's security decision-making processes, then ignorance of security in general and/or an open hostility towards user's security are widely prevalent within the organization.
I'm not speaking at all for Mozilla. Firefox 3.1 WILL contain a private browsing mode. It has been nicknamed "porn mode" by the press (well, that's one way you can use it for).
Perhaps we are forgetting there are many ways of stealing information from a computer, and there is nothing Mozilla can do to prevent most of this. As I see it by installing a system that temporarily stops information being stored prevents other users or unauthorised users from accessing some of the more sensitive information that had the potential of being stored on our personal computers. As for any other method of stealing sensitive data, I think it is up to the user to determine what they enter into their computer. Also don't forget while it may be possible to produce an algorithm to stop particular numbers being stored, credit card numbers and SSNs are not the only things being entered. The same algorithm may determine that data not associated with banking or any other sensitive information, should also not be saved which may prove difficult if the user did want it to be saved.
I think this really needs to be addressed. Currently, the argument from the WONTFIX side seems to be (indented, with my comments interspersed): > Users can disable autocomplete if they are paranoid. > Stored form data can be cleared by the user. > Users should use private browsing if they don't want things > recorded. > Specific entries can be deleted by selecting them in an. > autocomplete list and pressing delete. If this is a real security/privacy problem, then users cannot be expected to know how to work around it. Turning off autocomplete or clearing form data en masse is not satisfactory anyway as users may wish Firefox to remember their less private form data. An all or nothing approach simply isn't good enough. Likewise, private browsing isn't a solution if people still want their history recorded but just not private form data. For example I may find it useful to check the date/time that I visited an online store, and I may want the part numbers I ordered to be recorded from my form data, but I do not want my credit card number recorded. Furthermore, I think this is reasonable and is what most people would intuitively expect a secure browser to do. Note that unlike saving passwords in Firefox where the browser seeks confirmation beforehand, form data is saved to disk (or possibly the network for networked home/profile directories) straight away. Yes, there are ways to remove it later, but this may already be too late. For example, if I buy something using a trusted work computer with a networked home directory, then remove my saved form data a short time after, my credit card number could have already ended up permanently stored in the backup system where it may be compromised in the future. > It's not a security issue since if a virus has access to the > machine then all bets are off anyhow. A system may be completely secure and trustworthy at the time form data is saved, but it may later become compromised. For example, someone using my computer later may go to an online store to buy something for themselves but notice my card number in the autocomplete -- a crime that usually would require premeditation (to install a keylogger or other malware) suddenly becomes a crime of opportunity. Files containing the saved form data may be accessed through backups or via a browser exploit. > Form designers should use autocomplete=off. Yes, they should. Unless anyone can think of a way for this to be fixed on every problematic website though, we need another solution while the word gets around. > Because there may be false negatives in detecting private data, > or because false positives may cause innocuous form data to be > forgotten, nothing should be attempted. The difficulty of solving this problem should not stop us from trying to fix it. We can come up with reasonable heuristics for detecting private form data where the risk and cost of private information leakage is weighed against the risk and cost that banal form data is not remembered. Over time these heuristics can be improved to have smaller false decision rates. For example, a text field named 'cc' with 16 digits satisfying the Luhn algorithm is almost certainly a credit card number. The probability of getting a false positive here is practically zero. If there was somehow a false positive, I'm sure people would be quite forgiving of the feature having been trying to act in their best interest. In the case of false negatives (automatically saving data that should have been considered private), if this happened for less than 5% of websites, then that is still enough to provide significant protection. Other heuristics could be things like 'ccv' fields containing 3 or 4 digits, 'ssn' fields containing 9 digits, 'tfn' fields containing 9 digits, any field containing just 16 luhn-compliant digits, any field named 'credit_card', 'credit', 'ccn', 'cardno', etc. with 12 or more digits. If stored in a sensible data structure then people can submit patches to add other reasonable heuristics (which are judged by weighing the likelihood of false positives and false negatives).
If false positives (the event of Firefox not saving some banal form data) are a problem, a question bar in the style of "Remember this password?" can be implemented like in this mockup. I think the wording could probably be improved a little, but the idea would be that if the heuristics detected sensitive data, the user is prompted before Firefox goes ahead and saves this. The user can click the button 'More info' to see a list of detected fields, their contents, and what Firefox thinks they might be (e.g. Social Security Number).
Here is a proof of concept that shows that you can easily trick a user into giving up their credit card numbers or any other autocomplete data. Please note that it does not do anything with that data, so if your real CC number appears do not worry that I've done anything with it (feel free to check the source code). I have tested it on Firefox 3.5.3 on Linux. First make sure you have something to autocomplete in fields named 'cc' (which you can do at the top of the page), then play the game (it takes maybe 30 seconds) and see if it can get your CC number. Basically it leads you into quickly pressing a sequence of arrow keys and the return key to build up a score. At an opportune moment it focuses an obscured text input and effectively instructs you to press the right keys to autocomplete the form, where the sensitive data can be quickly taken and used. My game is obviously very contrived, but it wouldn't be particularly hard to write a side-scrolling platform game or a overhead puzzle game, or a tetris-like block game and claim to reward people who get high scores or something. Even just an image gallery which requires keyboard navigation could exploit this method. If this was combined with rendering bugs or other (possibly platform-dependent) UI bugs then it may be possible to do even more subtly or even possibly without user interaction. For example, I could have put a Flash video over the top of the "hidden" text field to make sure the autocomplete popup wasn't ever visible (at least on platforms where Flash gets drawn on top of everything). Throughout the course of a game like this, quite a number of different autocomplete fields could be probed for. If you were lucky enough to get fields for someone's credit card, expiry date and CCV then you can basically empty their account. I would argue that "exploits" of this type are not really avoidable, but it shows the seriousness of storing sensitive data in autocomplete fields. One way to prevent this would be to tie saved form data to the site it comes from, but I think it's also worth considering the detection of obviously sensitive information (as discussed in my two previous comments).
Please see comment #28 for the right solution (which isn't "reasonable heuristics"). See also http://www.w3.org/TR/html5/forms.html#attr-form-autocomplete Rather than adding comments here, email the web developers of the pages you are having trouble with and let them know about *their* security problem (it's not a browser issue).
Keywords: privacy
In addition to comment #63, I might add that it's not the job of the client software to protect the user from malicious or poorly designed Web sites. That's why Firefox doesn't protect the user against suspected phishing sites (imagine all those false positives). Could you imagine the chaos if Firefox warned users before submitting form data, or even when some elements of an SSL page were not loaded through SSL? Once the Mozilla Foundation went down the path of trying to protect the user from malicious or poorly designed Web sites they'd have to come up with elaborate mechanisms to protect against cross-site javascript attacks, pop-up windows, javascript that moves or resizes the browser window, man-in-the-middle SSL attacks, and so much more. I don't think we want to go there. In those cases, the operators of those Web sites should be contacted about their site.
I can't believe the developers are still ignoring this. Kieran Clancy very eloquently stated and demonstrated this. And Jerry Baker's sarcastic reply probably went over their stubborn heads too. I can't believe they spend so much time looking at fixing theoretical black-hat attacks, and leave something so obvious that any idiot could do.
The module owner and I agree that this should be fixed, at least for 16-digit credit card numbers (which cannot be confused with phone numbers thanks to E.164). I for one am not going to complain if that's the only thing that gets fixed *in this bug*.
Assignee: hewitt → dolske
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
Whiteboard: [sg:want?]
QA Contact: asa → form.manager
(I'm not actively working on this right now, but I agree we should take it.) If someone would like to assist by contributing pointers to the relevant credit card checksum standards (and bonus points for code implementing it), I'd be happy to assist with the actual patch/tests/integration. Basically, another check just needs to be added to http://mxr.mozilla.org/mozilla-central/source/toolkit/components/satchel/src/nsStorageFormHistory.cpp in nsFormHistory::Notify().
Assignee: dolske → nobody
Status: REOPENED → NEW
Whiteboard: [sg:want?] → [sg:want?][good first bug]
(In reply to comment #67) > If someone would like to assist by contributing pointers to the relevant credit > card checksum standards (and bonus points for code implementing it), I'd be > happy to assist with the actual patch/tests/integration. The short answer is that all major credit cards (including MasterCard, Visa, Amex, Discover, and Diners Club) make use of the Luhn algorithm for their checksums. http://en.wikipedia.org/wiki/Luhn_algorithm Though that Wikipedia page has a decent description of the algorithm, I did also come across this page which I thought had a particularly clear explanation of it: http://www.beachnet.com/~hstiles/cardtype.html With that in-hand, two potential approaches come to mind: --------- Wider net --------- One option would just be to check every form-field number against the Luhn algorithm. Advantages: * Less code to write. This approach also has either an additional advantage or disadvantage (depending depending on your point of view). Namely, the Luhn algorithm is used for more than just credit cards; it's also used for IMEI numbers, National Provider Identifier numbers in US and Canadian Social Insurance Numbers. (cite: http://en.wikipedia.org/wiki/Luhn_algorithm) So, if you were to simply check against the Luhn algorithm, those other types of numbers would be caught in the net as well. While it may or may not be desirable to prevent form autocompletion for Canadian Social Insurance Numbers (in addition to credit cards), I can't say whether it would be good or bad to prevent form autocompletion for IMEI numbers. ------------ Narrower net ------------ If the prior approach were considered too broad, potential credit card numbers could be checked against some additional criteria to help ensure that only credit card numbers are targeted. This page (also mentioned previously) has one of the better summaries I've seen of the specifics for various credit card providers: http://www.beachnet.com/~hstiles/cardtype.html (For instance, MasterCard cards are exactly 16 digits long and begin with either 51, 52, 53, 54, or 55.) Advantages to this approach: * No false positives. Disadvantages: * More code to write. * No "friendly" collateral damage such as Canadian Social Insurance Numbers. ---- Code ---- Though I have a degree in CS, my profession is as a front-end developer (XHTML, CSS, JavaScript), so unfortunately I'm not able to contribute much in the way of code for this. On the other hand, if there's anything I can help with from a pseudo-code or general-understanding point of view, just let me know.
Assignee: nobody → josh
I've implemented the checksum described at http://www.beachnet.com/~hstiles/cardtype.html and patched in a check into nsFormHistory::Notify, and run some manual tests against a page I'll attach as next.
Attachment #423333 - Flags: review?(dolske)
Attached file Quick test form (obsolete) —
A simple text input form for easy testing.
It's probably worth putting a length check in there. Obviously we want 16 digit numbers checked, but possibly also other numbers that use Luhn (social security, etc). Maybe make sure that the field has at least 8 characters, as a rough check.
Comment on attachment 423333 [details] [diff] [review] Quick and dirty Luhn checksum implementation This is basically fine (though I didn't run through the algorithm in depth yet), but I think this needs to do a couple of extra things: * First strip the string of whitespace and dashes ('-'), so that creditcard numbers entered in slightly munged formats will still be caught. [Are any other formats used internationally? Maybe forwards/backwards slashes too?] * At least to start off with, I think we should probably only apply the check to numbers with a specific length -- SSN == 9, and most credit cards == 16. The page you linked mentions some less common (?) cards with lengths 13/14/15, and I found a reference to some ISO spec for such numbers that seems to say they can be 7-20 digits long, but unless these are commonly used somewhere [again, internationally?] I think I'd prefer to initially err on the side of allowing these numbers to be saved... There's no perfect solution to detecting sensitive form data, and the wider we cast the net the more likely it is users will start wondering why things are broken an not saving certain values. [Eg, consider a form for entering 10-digit part numbers, some of which would just happen to pass the Luhn checksum.] Finally, we'll need to have tests that verify this stuff works (and to catch any future regressions). Could you generate a list of a few test values of each length (along with some negatives)? The existing test in /toolkit/components/satchel/test/test_form_submission.html should be easy to extend.
Attachment #423333 - Flags: review?(dolske) → review-
AmEx is 15-digit, so it should be checked. I would refuse to save *any* 15 or 16-digit number (after removing spaces and dashes) that passed Luhn, and I wouldn't bother with detecting SSNs at all 'cause I think false positives would be too annoying. (As a compromise, I don't think I've ever seen a SSN entered without dashes -- you might *only* look for and test 111-22-3333 and ignore 111223333.) It would also be nice, but not essential, if Firefox was capable of detecting adjacent entry boxes filled in a 4-4-4-(3|4) pattern and would concatenate and Luhn *those*.
I think it's important to *warn* when a number seems to be a Luhn number, and it should not be refused to store after all. It's just not only used for credit card numbers, but for other items as well, for instance IMEI numbers (which I'm using in my work a lot) or various serial numbers. It should always be possible to store such a number (although the warning should be the default), or even to disable the algorithm all together. The current patch doesn't do that, but that's fine for a first implementation (and for 99% of the users ofcourse). We might add other algorithms later, for instance Europe is now switching to IBAN for bank account numbers (ISO 7064), and you can probably do a check on most ID Card numbers, although every country seem to have their own checksum algorithm. If we start to refuse to store such number, and there are lot of different algorithms, we would have a lot of false positives. Hence the need to have a warning. Or maybe certain algorithms can be switched on or off depending on the localization (I wouldn't need the algorithm for a Chinese Resident Identity Card for instance).
Well, that's why I was ambivalent about even SSNs -- I think that we *should* silently refuse to store any 15 or 16-digit Luhn number, which will get credit cards and pretty much credit cards only. That's a sensible default behavior that nobody's really going to complain about, and it significantly reduces the value of Mozilla's cache to an attacker. Additional localized behaviors could be turned on in a config panel (block SSNs, block IMEIs), but you should need to go into about:config to disable the CC cache block.
For future reference, here's a python script I through together to generate valid arbitrary-length Luhn-satisfying numbers.
Now strings are stripped of whitespace and hyphens, and only ones of length 9, 15, and 16 are checked. Also featuring mochitests for all of these cases!
Attachment #423333 - Attachment is obsolete: true
Attachment #423334 - Attachment is obsolete: true
Attachment #424477 - Flags: review?(dolske)
Ugh, there are far too many repeated magic numbers in the tests, and it's really easy to miss one. Sorry for the bugspam.
Attachment #424477 - Attachment is obsolete: true
Attachment #424478 - Flags: review?(dolske)
Attachment #424477 - Flags: review?(dolske)
Comment on attachment 424478 [details] [diff] [review] Patch v2 with length checks + tests You're returning false if the length check fails. It returns PRBool so it should probably be PR_FALSE instead (like the other check).
Attachment #424474 - Attachment mime type: application/octet-stream → text/plain
Good catch, thanks. I've fixed that locally, as well as two other magic number mistakes in the tests so that they actually pass now. I've also filed bug 543322 about cleaning up the tests, because they're pretty frustrating to modify right now.
Comment on attachment 424478 [details] [diff] [review] Patch v2 with length checks + tests Mostly fine, just r- since there are a bunch of little nits I want to verify in a revised patch. >+// Implements the Luhn checksum algorithm as described at >+// http://www.beachnet.com/~hstiles/cardtype.html http://wikipedia.org/wiki/Luhn_algorithm seems like a more stable URL. >+PRBool >+nsFormHistory::IsValidCCNumber(const nsAString &aString) This can just be plain old "bool". We're slowly moving towards that. >+ nsString ccNumber(aString); This should be a nsAutoString, which uses stack storage instead of heap (for the common case of short strings, at least). >+ ccNumber.StripChars("-"); >+ ccNumber.StripWhitespace(); >+ >+ PRUint32 length = ccNumber.Length(); >+ if(length != 9 && length != 15 && length != 16) >+ return false; Part of me wants to do a (length<9||length>30ish) check on aString before doing stripping to allow bailing out early for common inputs... But that feels like over-optimization and makes things more complicated. A better alternative would be to handle skipping whitespace in the for-loop below; just track how many characters have not been skipped and do a early return when > 16. But, eh, I'm with with your approach too. Nit: "if (" not "if(". Nit: Would be s/false/PR_FALSE/, but ok as-is for a bool return type. :) >+ PRUint32 total = 0; >+ for (PRUint32 index = 0; index < ccNumber.Length(); index++) { >+ PRUnichar ch = ccNumber[ccNumber.Length() - index - 1]; s/ccNumber.Length()/length/ since you've already got it handy. s/index/i/, since that's a common pattern. >--- a/toolkit/components/satchel/test/test_form_submission.html ... >+ $_(13, "test1").value = "0000000000804609"; >+ $_(14, "test1").value = "000000000222331"; I'd like to see a bunch more sample values tested, so that we have greater confidence that things work and future changes don't cause subtle bugs x% of the time. Simplest way would be to add extra <input>s to each test form. Say, test01..test20. For the test data I'd hack up an online JS implementation (see Wikipedia page), feed it random input and dump() the ones it flags as ok. Should be sufficient to have one bunch of even length (16) and one bunch of odd length (15). The length-9 and whitespace tests are fine as-is. >+ $_(107, "test7").value = "0000000000804608"; Would also be good to add similar bunches of even/odd non-Luhn numbers, to catch any false-positive regressions.
Attachment #424478 - Flags: review?(dolske) → review-
Attached patch Patch with many more tests (obsolete) — — Splinter Review
All review concerns addressed.
Attachment #424478 - Attachment is obsolete: true
Attachment #433048 - Flags: review?(dolske)
This one actually builds, I swear.
Attachment #433048 - Attachment is obsolete: true
Attachment #433049 - Flags: review?(dolske)
Attachment #433048 - Flags: review?(dolske)
Attachment #194061 - Attachment is obsolete: true
Attachment #405751 - Attachment is obsolete: true
Comment on attachment 433049 [details] [diff] [review] Patch with many more tests Tested and verified that my credit cards are detected by this code. :-) Note to self: the 9-digit case is only for Canadian SIN numbers; the Wikipedia page is easy to misread as implying that US social security numbers (SSNs) are Luhn numbers, but they're not.
Attachment #433049 - Flags: review?(dolske) → review+
Pushed http://hg.mozilla.org/mozilla-central/rev/762e0cb1e093 Yay!
Status: NEW → RESOLVED
Closed: 22 years ago → 15 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a4
A possible unintended consequence of this is that if someone typos their credit card number, we're likely to save it in autocomplete (because it fails the Luhn check) where we wouldn't save the valid number. Then we'd suggest the *incorrect* value as an autocomplete for quite a while afterwards.
Well, couldn't the entry of a Luhn number instakill the autocomplete record for that field? Then they'd only get offered the wrong value once.
At risk of receiving a moar-configuration-smackdown that perhaps isn't entirely undeserved, is there any chance there could be a (hidden, natch) preference to control this behavior? Doesn't matter if it's non-live, just something where sticking it in user.js with the non-default value would toggle, for those people who don't want this assistance (maybe they prefer convenience to limiting risk, or perhaps hard drive encryption makes the point moot). Just suggesting here, if I don't get entirely shot down I'll file the followup.
MyTwoCents: This behavior should be toggled by developers with an attribute such as autocomplete as suggested. Also the browser could aid the forgetful or autocomplete-ignorant developers out there by spidering 7000 websites that offer credit card transactions and determining the most common credit card name="" attribute values for credit cards. I expect a short list of name values such as: cc_number creditcard_num etc would show up. Regexing the strings catches too many false positives. If it's good enough for Microsoft to analyse the top 7000 sites for real world usage, why can't Mozilla? It's not likely a perfect science but it's a start.
Blocks: 46590
I'm late to the party (blame Jesse for cc:ing me ;-), but I think there is an important disconnect between the PoC in comment 62, and the current sentiment in the bug (blocking valid credit card numbers). If you accept the premise of autocomplete, preventing autocomplete of credit card numbers specifically should not be browser's business. Given the types of information that autocomplete picks up, there is nothing special about credit cards: social security numbers, bank account numbers, DL numbers, national ID numbers in a variety of countries, can be equally sensitive (e.g., can be abused to obtain credit, forge checks, authorize wire transfers, and so forth). In fact, the impact of leaking many of these is far more serious, because there is a limited liability for unauthorized CC transactions, and the ease of replacing them; but if your SSN is leaked, you will be in long-lasting trouble. I can practically guarantee you will see a request to filter out SSNs in the future, on the same grounds. Critically, though, autocompletion of these long numbers and perhaps your home address and e-mail address (which I also don't want to accidentally give out to random websites, by the way), are probably the most important reasons why people use autocomplete in the first place, right? If so, then blacklisting all of the sensitive stuff means you are essentially sort of giving up on the mechanism. I have two radical thoughts that I am pretty sure will not be liked, but I feel obliged to mention them here anyway (and then shut up): 1) If you are determined to follow the path of blacklisting all the sensitive stuff, maybe you should scale back to an explicit mechanism that scratches specific use cases that still remain on the table (because of an acceptable risk in the current "hijackable" design). Say, allow the user to enter his contact information in a configuration dialog, and only autocomplete using this data? 2) If you do not want to scale back - then, in light of comment 62, it would seem necessary to alter the user-friendly but unsafe behavior of autocomplete, so that we do not end up leaking random bits of accidentally amassed sensitive information to third-party websites. The two obvious solutions is requiring a more explicit / unlikely gesture for autocomplete to kick in on a page; or having a UI solution that, for example, ensures that autocomplete drop-downs are always shown on top of any other DOM, and get a certain amount of uninterrupted screen time before a choice can be made. /mz
Comment on attachment 405751 [details] "Remember this form data?" bar mockup For those wanting this behaviour to be configurable, see how this could be done consistently with other privacy-affecting-data-storage in the mockup (attachment 405751 [details]). It seems that at some point the attachment was accidentally marked as obsolete. @Michal (in reply to comment #90) There are two separate issues here: 1. Storing sensitive data without the user's go-ahead means it ends up on disk (which may be on the network), and could be compromised at some point. To solve this we need better control over what gets stored and what doesn't; whether by heuristics (the currently proposed solution), and maybe by better UI (which I think wouldn't hurt - see mockup). 2. Malicious websites may be able to access autocomplete contents. That's probably best for discussion in another bug. I posted the PoC in response to a number of people who seemed to be saying "this is not a problem" or "users can manage this themselves".
Attachment #405751 - Attachment is obsolete: false
As a user I understand the implications of storing data on the system. Any data that is stored can be retrieved. However my concern is that I am unable to take advantage of the auto complete feature because it has been designed to do the opposite of what it suggests. I don't feel as if I can say Firefox "is my web browser" if this software can not do what I want it to. Please allow the auto-complete feature to work and automatically complete any and all forms. Blocking forms is counterproductive and if the developers take the "user is dumb" approach then auto-complete needs to be removed from the code because there is more sensative information besides credit card numbers that can be stored. Besides even if the credit card number is stolen the card holder is generally not liable for any misuse of the account.
Andreas van dem Helge display an astonishing naivete with this comment: Please allow the auto-complete feature to work and automatically complete any and all forms. Blocking forms is counterproductive and if the developers take the "user is dumb" approach then auto-complete needs to be removed from the code because there is more sensative information besides credit card numbers that can be stored. Besides even if the credit card number is stolen the card holder is generally not liable for any misuse of the account. First of all, he probably doesn't realize the damage that can occur to someone's credit rating if a credit card number is stolen. The obvious is the amount of time and energy spent to address the fraudulent charges. Less obvious is that someone's credit score could be damaged by such incidents, before they are finally cleared up, weeks or perhaps months later. A damaged credit rating could mean that someone is denied a mortgage or auto loan application, or is forced to pay higher interest charges. It could also affect someone's job prospects, because of a negative credit report. These are not inconsequential. Finally, he is wrong in stating that some is generally not liable for misuse of the account. Someone could be held liable for the first $50 of a loss, and that is true only in the US. In Europe, there are no such consumer protections. Finally, it is highly irresponsible for Firefox not to exercise "prudence" in such a sensitive area. It's not that the user is "dumb," it's that 99.9999% of people simply don't understand these issues. To say that the "user is dumb" approach needs to be changed is the height of developer "high priesthood" arrogance.
I not saying that we should be sharing the credit card to the social networking sites either. But if we are to protect the user against their own actions in one aspect then we should take the responsibility to protect them against all their actions. In the USA arguably the social security number is much more sensitive and has more chance to be exploited for identity/credit theft, however Firefox does not protect the user against their own use of this information. Further there are people who are in victim or witness protection programs. They are placed in this situation because they have been e.g. victim of a violent crime, domestic violence, etc or e.g. testified in criminal proceedings against an organized crime ring. Many of these people are Firefox users and complete web forms online. If their identity or private details are misappropriated the consequences might be much more devastating than the release of a relatively insignificant credit card number. There is also unfortunately illicit material online. The material itself might be illegal, or the only purpose of the material might be for illegal acts. The consequences of these materials may be loss of freedom or even death. Firefox users should be protected against these threats by disallowing the use of Firefox to interact with these sites.
I realize that you may be trying to be facetious but your example is clearly off base. If you had termites in your house, do you destroy the whole house or just resolve the termite issue? The storage of CC issue can be just as simple as someone not wanting their, not old enough, child to buy something on a website just because they were able to type in a few starting #s.
To some extent yes, but it does raise a valid question: If we deem that the user does not have the mental capacity to be presented with information and make a decision for some security related matter, why do we deem they have the metal capacity to make these choices for other security related matters? The president has been set by Firefox developers that the user should not be able to choose some things for their safety. We therefore need to make sure that these decisions made for the user are consistent. If you really want to know: 1) I would probably call an exterminator. They would assess the situation and give me options. I would be under no obligation to proceed with their recommended course of action. If I wanted to I could CHOOSE to continue living in the house until it collapses. If the roof falls on my head and kills me, who is to blame? 2) Hence why auto-complete can be togged off. But since we are making the decisions for the user, we should change this to report the parents to the authorities for child endangerment for leaving a child unattended. Or we could just assume that people generally have the mental capacity to decide for themselves what they want and just like warning messages are shown for certain events, the user could be prompted along the lines of "You have submitted a form containing credit card information. Storing credit card information can be insecure as anyone with access to your computer could retrieve the stored information. Are you sure you want to continue storing this data? [x] Remember this selection. [Yes] [No]"
I can maybe understand making it configurable (maybe in about:config), even though I don't see the need for it. I think Andreas is overblowing the "I can't use the feature how I want" issue. If we look at all the possible downsides of storing a CC number (impact to credit rating, depleted checking account with debit card compromise) and the ways in which it can be compromised via autocomplete (unauthorized use by a child, theft from the autocomplete database, some other phishing/exploit) vs the 3 second inconvenience typing manually inputting the numbers (which you often don't have to do for regularly visited sites like Amazon or Ebay), the calculus is clear. Furthermore, it's ridiculous to bring up people witness protection programs - it's creating a false dilemma. Firefox can easily prevent the accidental compromise of credit card information - credit card numbers adhere to a well defined algorithm, so it's relatively simple to accomplish implement. Just because Firefox can't protect users from all forms of far less common information disclosure doesn't mean it shouldn't protect from credit card number disclosure. In fact, Andreas brings up a good point that SSN's should probably be excluded from autocomplete as well.
Please don't post long-winded back and forth arguments over long settled issues like this. Credit card numbers are filtered out of autocomplete because they're easy to detect with an algorithm. Social security numbers and some other IDs probably should be too, but that would be a lot more work and another bug. Even for people who "know what they're doing", having these sorts of things in autocomplete lets that info be available for exploits to steal autocomplete data. Sites that really need to remember credit cards should do so on the server side, and plenty do. Now, please stop arguing about termites and witness protection.
Depends on: 1166895
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: