Credit Card Numbers Still Google-able 157
If you have a Visa, Mastercard, or Discover Card number handy, do a Google search for the first 8 digits in the form "1234 5678" (don't forget the double quotes around the numbers, and the space in the middle). The odds are that you will find at least some pages among the search results which include other credit card numbers that begin with the same 8 digits. Those Google hits will frequently be in the form of a spreadsheet or document that looks like it was made for someone's internal use and wasn't meant to be leaked on the Web, and some of those documents will include entire lists of other credit card numbers as well. (The search trick doesn't work for American Express cards, since their card numbers are usually stored in the form "3xxx xxxxxx xxxxx", and it's far less likely for your card to share the same initial 10 digits with someone else's credit card. But of course if you hit on a page that contains a list of credit card numbers, there will probably be some AmEx cards in that list.) Of the pages that I found containing leaked credit cards, often they would also contain other sensitive data like passwords and social security numbers. Don't do anything I wouldn't do.
In my 2007 article, I wrote, "Of course, it's not the card companies' fault that these card numbers are leaked onto the Web; it's the fault of the merchants that allowed them to get leaked. But the credit card companies are the only ones who are in a position to do something about it." I suggested for credit card companies to run a Google search every day or week for all of the possible 8-digit prefixes that could correspond to their card numbers, and then to deactivate any card numbers that were found in this way. They could also send a request to Google to remove the page from Google's index because it contains credit card numbers (there is already a public-facing removal request tool for this purpose). And finally, if it was a merchant that leaked customers' credit card numbers online, then the merchant should be sanctioned as well.
The problem with all of these suggestions is that there doesn't seem to be sufficient incentive on the part of the people who have to implement them. If a credit card company has to refund a fraudulent charge, they usually just take the money back from the merchant who originally received it, and it costs the credit card company nothing. (During my brief stint running a company that accepted online credit card payments, sometimes a "customer" that we had interacted with and who definitely knew who we were, would decide to call their credit card company and "dispute" the charge for no reason, and the card processor would just take the money out of our balance and hand it back to the customer.) So credit card companies themselves apparently lack the incentive to fix the problem.
So perhaps the easiest fix could come from Google, a company that actually has no incentive at all to fix the problem, except for the fact that it would be a neat idea. Although their "Don't Be Evil" motto has taken a lot of beatings, they still do some basically responsible things for reasons that don't seem to contribute directly to their bottom line. (The fact that they have a tool at all for requesting the removal of pages containing credit card numbers, for example.)
It should be pretty easy for Google to run its own queries internally, based on all possible 8-digit credit card prefixes, to find pages that list any sequence of 16 digits beginning with those 8. Then could do a quick mathematical test on the 16-digit sequence to see if it's a valid credit card number. Then scan their own cached copy of that web page to see how many other valid credit card numbers they can find. Then propagate all of those numbers back to contact points at Visa, MasterCard, American Express and Discover, saying, "We found this credit card number leaked onto the Web; you should cancel the number and issue a new one."
After that point, should Google delete the page from their search results themselves? On the one hand, it clearly helps reduce credit card fraud to remove pages from their index that contain working credit cards. On the other hand, the purist in me doesn't like the thought of Google removing information from their index. After all, if the problem is that a list of credit card numbers has been leaked on a webpage, having that page show up in Google shines a light on the problem; removing it from the index doesn't make the problem go away. (The page could still be found through other search engines; or credit card thieves could have already found the page on Google and saved a copy before Google de-indexed it.) Perhaps a compromise could be that once Google has received confirmation from the credit card companies that all of the card numbers on a given page had been de-activated, it could restore the page to their index, but it would be displayed in search results with a warning saying, "This page contains personal credit card account information; all of the credit card account numbers listed have been de-activated."
Unfortunately this doesn't work if the page also contains other sensitive information that can't be un-compromised just by closing an account — e.g., Social Security Numbers, or addresses and phone numbers. (In any case, Google's removal policies specifically say that they won't remove a page from their index just because the page contains a person's address or phone number.) So maybe the better answer really is to just leave the page out of the search results permanently, over the objections of the "purists."
(I may or may not have found some evidence that Bing is more aggressive about removing pages from search results that contain credit cards. I took a "trove" of 11 credit cards that I found through one of my Google searches, and for each of the 11 card numbers, ran a query on both Google and Bing for the first 8 digits. On Google, 8 out of the 11 queries returned at least one page containing more credit card numbers, not counting the original page which had had supplied the "trove" of numbers that I started with. On Bing, however, only 3 out of 11 queries returned pages with more card numbers. This could indicate that Bing is more conscientious about removing pages from search results that contain sensitive personal information. Or it might just mean that they're not as good as Google.)
Of course the fundamental problem with credit card number security has always been that you have to use the same "token" — your credit card number — for every purchase, with every merchant. (There are card companies that let you generate one-time-use numbers for every purchase, but almost nobody uses those.) Maybe in a few years, credit card numbers will be supplanted by more secure payment protocols and fall by the wayside, but that's also what I thought in 2007.
Many are Fake (Score:5, Interesting)
There are thousands of pages of fake credit card numbers, SSNs, etc. This is done intentionally to dilute the value, and some are probably honeypots. The numbers are bogus, expired, etc. that pass the checksum.
Nothing for me... (Score:5, Interesting)
I tried this and found an interesting page (Score:5, Interesting)
It seems that people are deliberately creating millions of fake identities and putting them online just to screw with the bulk data collectors.
Read the explanation on this page: http://xdduk.org/nino/BT889440D [xdduk.org]
It Used to Be Even Easier (Score:4, Interesting)
Google has a little-known search operator for finding numbers within a range. To find all numbers between two numbers, you Google the two numbers separated by two dots. For example, to find all numbers between 87600 and 89061, you'd Google "87600..89061" as shown below.
https://www.google.com/search?q=87600..89061
It used to be that you could simply Google a large range of possible credit card numbers using this operator and find tons of numbers. However, a few years ago, Google put a stop to this by forbidding number range searches involving large numbers.
For example: https://www.google.com/search?q=8760000000000..89061000000000
It's unfortunate and disappointing that Google crippled its search engine to solve the problem, as there are lots of legitimate reasons for searching number ranges involving large numbers.
Re:So what (Score:5, Interesting)
What merchants? Searching for the first 8 digits of a Wells Fargo Mastercard brings up an Excel file with several worksheets in it, including one that lists a bunch of websites and login information (including bank websites). It's on a user's FTP share at their job. So someone decided to put their important file there and they have no clue it's publicly available.
Re:Nothing for me... (Score:5, Interesting)
I tried this with the first eight digits that I got out of a credit card generator (I'm not going to type in my own). The second result as a Word document that contained a full credit card number, expiration date, security code, and name. The .doc was hosted on a website (csonet.org) that claims to be part of the United Nations. So, I did the usual whois lookup and it started looking fishy, like a honeypot: registered to a company that sounded like a front company ("anywhere design" and "computeragent.net"), and really, why would someone post on the web a Word document with exactly the information you need to make a fraudulent transaction? And isn't the UN a bit more competent?
Then I visited the UN's web page and, son of a bitch, csonet.org is plastered everywhere on the actual UN site: it' s apparently how you apply to get money out of the UN. See http://www.un.org/womenwatch/daw/csw/NGO.html for an example. Holy fucking diplomatards, BanKiman! If they're posting credit card info with full validation information online there, what's the rest of their security awareness like? No fucking wonder the UN is a playground for the NSA, CIA, KGB, GCHQ, and everyone with unjustifiable budgets that match only their unjustifiable egos.
Different incentives (Score:5, Interesting)
The value ain't worth the time spent.
If you have to spend 1% of your time/money fighting fraud, well once the amount of fraud drops below that 1%, it isn't worth fighting fraud.
To you.
The problem is that a company might loose only
But to the
The incentives for the corporations are different from those for individuals. Imagine that.
Re:Comment Subject: (Score:5, Interesting)
A bit of anecdote from a client's site I used to work on...
Client was complaining of some random issue and I went to take a look. Right away I was prevented from doing so because he changed his FTP/SSH permissions and I wasn't able to access the files.
I decided to poke around the front-end to try and find clues while I waited for him to respond with a fresh set of credentials. Eventually, I came across a server log that was mistakenly made available to the public at large (though you would have to know the URL to find it). Inside the log file were hundreds... probably thousands of records of customer information, including last four digits of their CC used for payment (if they had one).
I immediately got back to him about to tell him this information was available on his site to anyone and said that I could fix the permissions once he allowed me access. Unfortunately, he never did get back to me and it was a short time afterward that I was fired from that job (thank god).
I didn't develop his site, but I do know the person who did, and he happens to be a director at the company. Out of curiosity, I just checked, and the information is still openly available on his site, and it's been like 8 months. Now, though, there seem to be some additional logs of juicyness. 'authorize_net.log', 'google_checkout.log'....
To top all this off, he used to (not sure if he's come around by now by I doubt it) store customer's CC info in the store database. Before he started using this, I warned him that it was not a good idea, but he said it was the best way. There can be no way his site is PCI complaint, so in all likelihood an audit would completely put him out of business.
Re:Many are Fake (Score:4, Interesting)
It's called a Luhn check, and it's so dirt simple, you can do it in your head if you passed 4th grade math.
1) Reverse the number (this is not actually necessary, but it's part of the "official" algorithm).
2) Now, treating the number as an array of digits, take the even-indexed digits and double their values. Don't worry if they overflow to double digits yet. (If you skipped step 1, you'd simply do this operation to the odd-indexed digits.)
3) Add any double-digit values' digits together (e.g. 12 -> 1+2 = 3) and use these in place of the double-digit values in the array.
4) Sum the contents of the array.
5) Sum of the array, modulo 10. If this is 0, it's a valid CC number.
The easiest way to remember a test card is to remember Visa 4111 1111 1111 1111. All Visa cards start with 4, fill the rest of the digits with 1. When you apply the Luhn check:
1) 1111 1111 1111 1114
2) 1212 1212 1212 1218
3) 1212 1212 1212 1218
4) 30
5) 30 % 10 = 0, pass.
Any competent programmer should be able to reverse this process to generate numbers that pass this test. In fact, a reasonably good program could probably generate all valid Luhn-able numbers in a few seconds, and store them in whatever format you wanted. Like pushing them out to a Google docs spreadsheet that's open to the world. Then, everyone's credit card is "compromised", while no one's credit card is actually compromised. Now the "bad guys" have to come up with a noise filter on their searches.
Re:Nothing for me... (Score:2, Interesting)
It's their database manager/web monkey, a Swede named Ola Göransson. He's apparently been using the NGO Committee directory for his personal files. His name is on the whois registration and on the Word document (I'll leave it to the reader to figure out how to google for "credit card" info on the site csonet.org).
Here's his resume, along with a dolichocephalic, tired-eyed photo: http://csonet.org/ngocommittee/content/documents/app_form_4913.pdf [csonet.org]. His skills include PHP, ASP, and doxing himself, with full credit card info, like an international boss on a United Nations server.