Stealing 130 Million Credit Card Numbers

Someone has been charged with stealing 130 million credit card numbers.

Yes, it’s a lot, but that’s the sort of quantities credit card numbers come in. They come by the millions, in large database files. Even if you only want ten, you have to steal millions. I’m sure every one of us has a credit card in our wallet whose number has been stolen. It’ll probably never be used for fraudulent purposes, but it’s in some stolen database somewhere.

Years ago, when giving advice on how to avoid identity theft, I would tell people to shred their trash. Today, that advice is completely obsolete. No one steals credit card numbers one by one out of the trash when they can be stolen by the millions from merchant databases.

Tags: , , , , , , ,

Posted on August 27, 2009 at 7:02 AM • 46 Comments

Comments

Chris • August 27, 2009 7:29 AM

“No one steals credit card numbers one by one out of the trash when they can be stolen by the millions from merchant databases.”

I have to disagree a bit here. Hackers and professional fraudsters may be stealing credit cards by the millions, but teenagers, meth heads and other small timers are still interested in trying to lay their hands on a number if it’s available the old fashioned way. Different threats from different classes of criminal.

Randy • August 27, 2009 7:35 AM

I’ve always wondered why merchants would want the responsibility of keeping all of their customer’s CC numbers in a database where they can be stolen.

I know Amazon’s “One Click Purchase” button would be impossible, but I don’t have that turned on and I will still make online purchases even if I have to reenter my CC every time I want to order something.

I also wonder if one-time CC numbers would help to eliminate this threat.

Randy

J.M. Schneider • August 27, 2009 7:53 AM

Two words: Data Mining.

While transactions have their immediate value, it’s the ability to project trends that entices merchants to store that data for future use. Shame that their penchant for scrying never gives them the insight to understand that something of value to them would be of value to others as well.

In this case, one-time numbers would seem to diminish the value of the individual transaction (since the same number is unlikely to be used twice in any relevant time frame [or at least that’s the idea]), possibly forcing vendors to base their forecasting models strictly to product transactions. No doubt, there would be some push back (if there hasn’t been already).

r • August 27, 2009 8:23 AM

According to the article, “Gonzalez is a former informant for the U.S. Secret Service.”

So, he was a known criminal. No surprise that he engaged in criminal activity.

Presumably, the SS allowed him to remain at large to assist in catching bigger thieves. Now they find out he was “the ringleader.”

They were played. Sad.

Dirk Wetter • August 27, 2009 8:24 AM

It all depends on the size of the merchant and where the compromise takes place. One remarkable detail with respect to that is that some POS device still don’t offer anything better than WEP (they are still allowed to do so by PCI DSS until Q3 2010). As a rule of thumb. I would also think that the smaller the merchant (=DB with CC infos), the worse the protection.

D • August 27, 2009 8:32 AM

@J.M. Schneider

I don’t see how using the CC number validates trend analysis. Every site that I order from insists I have a login account. If I use my account to order something, they know it’s me. If a site doesn’t require an account, then there’s always the shipping address to link purchases.

Storing a CC number in a database is for “customer convenience” and that’s all.

Ian • August 27, 2009 8:32 AM

Data mining based on card number could be accomplished by always storing a hash of the card number. This also allows customer support queries (“find me the last transaction on this card number”) without requiring sensitive data to be stored.

There are many cases where the card number must be stored until the transaction is complete. This applies to hotels, car hire, and mail order merchants who may not charge the card until the item is ready to ship. Some systems authorize in real time but send a file containing all completed transactions at the end of the day.

Also, it’s not only the database that needs protecting. Network sniffers can extract the card number from in-flight transactions if the communication link is not secured.

A big part of the problem is legacy systems which didn’t regard the card number as sensitive data. Newer systems have stricter security around this, but replacing old systems takes time and money. If the cost is too high, the merchant might prefer to just take the risk. Developing new standards like PA-DSS and increasing the penalties for non-compliance is forcing legacy systems to be upgraded.

Randy • August 27, 2009 8:32 AM

@JM

It seems to me the merchants could hash the CC# or use my name and address as my unique ID instead.

It just seems to me that they really don’t care. But then, I guess that is obvious.

Randy

gdfuego • August 27, 2009 8:40 AM

If you do use a hash of the credit card, you’ll want to make sure you hash it with additional data like the name on the account, zip code, etc. Otherwise you’ll just see people starting to create credit card number rainbow tables.

They are longer than a password you’d usually see tables for, but their character set is much more limited.

dude • August 27, 2009 9:03 AM

@gdfuego

Rainbow tables are not going to help if a proper sized hash is used. Its still a time/memory trade off.

tanish • August 27, 2009 9:05 AM

i have a query here.

do you think with the new VISA 3D, Mastercard secure protocol which requires a customer to answer a secret question directly to bank, could actually end this credit card retention cries by online retailers ?

FP • August 27, 2009 9:36 AM

I always find it amusing how banks use the ID theft argument in trying to convince me to switch to online-only statements: “Paper statements are an identity thief’s best friend.”

On a related note, merchants started asking me for the CVV (the three- or four digit number on the back of a credit card) over the phone recently. It used to be for automated processing for online purchases only, and under no circumstances were you supposed to reveal the number to anyone. So much for that.

Clive Robinson • August 27, 2009 10:05 AM

Why do people keep credit card numbers…

Well at one point it was like a social security number a useful unique identifier that could be used as a “primary key” in a database.

A more recent reason is “charge back theft”. Not all CC theft is by stolen numbers some is by people making a purchase receiving the goods and then denying they had made the purchase. Often the merchant is hung out to dry by the credit card companies. Without going into the why or the where of it some merchants keep the details to protect themselves and others from these types of crook.

Oh and something else you need to consider a hash is by no means a good solution to the problem. To remain probably unique it needs to be considerably larger than the small sized unique CC number. When you have to store many many credit card transactions this sort of thing counts, especially when the CC number gives other info as well which you would lose by hashing and thus need to make another field in an already “to large” record.

Ian • August 27, 2009 10:16 AM

@Clive, a hash is not a complete solution, but it’s a good solution to at least two problems where you would otherwise have to store credit card numbers: (1) trend analysis (where a few hash collisions are not significant), or (2) searching for a transaction using a particular credit card number (where other information such as the transaction amount could be used to resolve the ambiguity resulting from a hash collision).

joe • August 27, 2009 10:16 AM

There are other good reasons to shred personally-identifiable trash… and if that’s not a good way to get good stuff, you might want to tell the bums and such that search through trash in SF for receipts and other material. I’ve never asked them what they do with it, but they don’t get much from our trash.

Clive Robinson • August 27, 2009 10:25 AM

@ tanish,

“do you think with the new VISA 3D, Mastercard secure protocol which requires a customer to answer a secret question directly to bank, could actually end this credit card retention cries by on-line retailers ?”

Probably not.

The first question you need to ask is, Who benefits by this system “the bank”, “the merchant” or “the customer”?

The second question you need to ask is, Who loses by this system “the bank”, “the merchant” or “the customer”?

The third question you need to ask is, What is EVM’s track record on secure protocols?

Or to put it another way as a customer why should I use a system that circumvents (takes away) my legal rights in favour of EVM who like the banks have a poor track record of responding correctly to security issues?

If you are not convinced have a look at the history of SET and Chip-n-Pin. SET was a failure because it was not in the customers interest, and Chip-n-Pin is regularly having it’s protocols changed to plug holes in it’s security,

http://www.cl.cam.ac.uk/~sjm217/papers/cl05chipandspin.pdf

David • August 27, 2009 10:30 AM

@joe
Christ, if you live in SF it’s a good idea to just shred, burn, dig a hole in the garden and bury, anything at all that could ever identify you on paper. Even the psychotic bums are information savvy there.

Clive Robinson • August 27, 2009 10:36 AM

@ Ian,

“but it’s a good solution to at least two problems where you would otherwise have to store credit card numbers”

For new DBs maybe but for existing DBs?

Try selling it “as such” to the DBA who has a 200 million record DB that he now has to completely re-build, changing the data size and type of one field (probably primary key) and add at least another field, whilst telling him you cannot guaranty that the unique field will remain that why and oh also that nearly all the written queries reports and other code will have to be changed as well.

I have a feeling that you would not be popular…

Why do you think the CC Industry has had to go down the heavy handed route over storage of CC numbers?

Peter A. • August 27, 2009 11:03 AM

As to the merchants needlessly storing CC data:

USA banking system, online payment and security practices are sadly little behind the systems of smaller countries – mostly because of their large size and legacy that makes upgrades very costly.

Here in Poland virtually no online merchant stores credit card numbers. Credit card processing companies offer special services for secure online payments that easily integrate with merchant’s web service. The merchants system simply prepares an URL pointing to the CC company’s service with his merchant ID, transaction ID, amount and other data encoded in it. By clicking on ‘pay now’ button your browser gots redirected to the CC company’s website (SSL secured) which you can trust. There you enter your details and click ‘accept’. The transaction is authorized online, and your browser gots redirected back to the merchant’s web page with success/failure indication. The merchant never sees your CC number.

Also many local banks offer similarly working services, that transfer funds directly from client’s checking account into merchant account at the same bank, instantly. One example of such a service: http://www.mbank.pl/en/personal_banking/accounts/personal/eKONTO/#tabs=3

Most CC companies’ payment services also integrate the various banks’ payment options like the one described above as an alternative to CC payment with no difference to the merchant. This allows people with no CC but only checking account pay online securely. One example: http://www.ecard.pl/internet-payments.htm (their English-language page is slightly outdated as more payment options are currently available, but should give you an image of what it’s like)

As far as I can tell the only merchant that keeps my CC data is Amazon.com 🙂

Alex • August 27, 2009 11:03 AM

Clive, the hash field can be made unique by the addition of a sequential number/string (i.e.: a nonce), in plain text, in the field, that gets hashed with the CC #. Or if you can deal with nearly impossible odds instead of absolute, just salt the hash. The odds of a collision are so low as to be impossible the nonce just enforces uniqueness.

David • August 27, 2009 11:28 AM

@Clive
DBAs get asked to do such things all the time and I haven’t designed a schema in over 14 years that had a field for credit card data in it. You simply say from the outset, “this is not something I as the responsible application designer am prepared to be accountable for being compromised.”

Same goes for any other UID that may have financial or legal implications. I think any DBA would agree that a redesign that limits their liability is a popular idea.

Kim Hersh • August 27, 2009 11:31 AM

Randy –

I’ve found that one-time CC #s aren’t all they are advertised to be either. I’m guessing they might help somewhat, especially when shopping at smaller, more specialized places where thieves are less likely to use the #s, but at larger places, where one is most likely to shop, such as Amazon, ebay, buy.com, and places like that, I think the one-time use number does almost nothing for you.

Why do I say that? My experience in using them at Amazon. I had used a “one-time use” number at Amazon. At the time, it was next to impossible to delete all credit card numbers from one’s Amazon account – they’ve since made it easier. So – I made sure that the one number left was one of the “one-time use” numbers, figuring that it shouldn’t be able to be used again.

But later on, when I went to make a Kindle purchase, I had figured it would come up and tell me the card was not valid and ask me for a new card. Instead, the charge went right through. I was able to continue making purchases on the “one-time use” number until the expiration date passed, which was a year or more after the original charge.

Now I’m guessing that number wouldn’t have worked at any other merchant. And maybe no one else would have been able to use it fraudulently. But it certainly wasn’t one use. I kind of understand it – the CC company has to be able to allow for returns, exchanges, and the like, and to do that, they have to allow more than one transaction to take place on the card. But you would think that the way the number ended up being used would have raised a flag. It didn’t.

Andrew G. • August 27, 2009 11:57 AM

I think this is the first time I have disagreed with Mr. Schneier. While the risk of credit card numbers being taken via large databases is higher than someone getting it in the trash, it appears that the risk someone will actually misuse your numbers is higher if they get them through the trash (I have no studies to back this up). And shredders are not that expensive to buy and operate …

Peter A. • August 27, 2009 12:17 PM

Kim Hirsh and others:

One-time numbers may not be of much use if there are no or little limitations for its use as you have experienced.

One “secure” card I use has a different feature. It has a “permanent” number but no physical form (so you can use it only remotely: via Internet, telephone etc.). The important thing is that its authorization limit is user-settable. Normally it rests at zero so no transaction would be authorized. Before making a purchase you log in to your bank’s online system and set the limit to the amount needed, or a little more just to be safe (especially when currency change is going to happen). Then you proceed with checkout on the shop’s web page. You can see the transaction amount deducted from your limit after the authorization completes and the funds are put ‘on hold’. Then you ‘discharge’ the card setting the limit back to zero. A few days later when the transaction is fully accounted for, you may see funds deducted from your balance. That’s all.

Even if someone steals the card number from some database or while in transit to the shop’s web page there’s very narrow chance for the attacker to make use of it.

Clive Robinson • August 27, 2009 12:35 PM

@ Alex,

“the hash field can be made unique by the addition of a sequential number/string”

I’m aware of some of the various ways it can be done, however they all have disadvantages in one way or another. In essence to hide the CC# with a hash you need at least twice the storage required for the CC# on it’s own. And you also lose information in the process.

Neither are major issues when done correctly but that is the rub, and as a result they can have a significant impact on the DB performance.

@ David,

“Same goes for any other UID that may have financial or legal implications. I think any DBA would agree that a redesign that limits their liability is a popular idea.”

Then why is it not being done?

If it was we would not be having this conversation, because 130million records would not have gone walk about (though the time period over which it happened is a little open at present as is just how unique each record is).

There are many many reasons why a DBA cannot or will not make this sort of change even when fines and or financial liability is involved and the directors and above are aware of it. It often boils down to a simple risk/cost calculation.

That is the perceived risk of being caught and fined -v- the perceived business risk and cost.

Most senior execs know that they have a tenure of less than 18months and that their next job is dependent on been seen to maximising some aspect of the current business that would be of interest to the next companies share holders.

This significantly effects the way they calculate risk as they assume that they are smart enough to jump the gun and not get caught. Some of the brighter ones ensure that there is a liability limitation layer between them and those actually taking the risk in the same way that politicians have “deneibility”.

Those taking the risk get promoted those not get moved sideways or outsourced.

as • August 27, 2009 12:56 PM

He faces life in prison. What the hell? Life in prison for stealing imaginary money and shifting around digits? What about all the violent criminals who actually hurt people and not just insurance companies and credit card firms? Oh right, they’re not as important and if you’re a “hacker” you’ve already committed the ultimate sin.

Clive Robinson • August 27, 2009 1:05 PM

Oh just one thing…

How do you know that the CC# is not stored when an auditor comes in to check?

Your CC# is approximately 15 decimal digits giving which if my brain is functioning about 54 bits of data.

Therefore the CC# can simply be encrypted against a fixed key buried in a code library somewhere masquerading as a hash.

This has the advantage of having a one to one mapping therefore uniqueness is preserved and of course the CC# itself is not stored (just the encrypted version). Importantly to those in the know it’s reversible. To those not in the know it’s just a “long long” or whatever storage is large enough to hold it.

As you have ten bits at the top to play with prior to encryption, any old number can go in there such as the XOR of the first and last three digits of the CC#, you could legitimately call it a hash (obviously not a one way hash) and get away with it…

I can easily see some people doing this sort of thing for quite a few reasons, with quite a high probability of getting away with it.

Andrew H. • August 27, 2009 1:36 PM

Data mining is NOT the only reason a merchant would want to store credit cards. I think by far the more important reason is that it reduces the amount of effort a customer needs to complete a transaction.

This is why Amazon encourages you to turn on one-click, stores your credit card number, and offers Amazon Prime (a program where you prepay an annual fee to get free shipping on all purchases). It’s all about reducing friction for each individual purchase.

And it works! I certainly prefer to buy from Amazon than from other vendors, because it is a couple clicks and a single password entry, rather than entering complete address and credit card information each time.

The Polish system Peter A. describes above seems like a good way to get the benefits of easy payment along with the security of having only one entity (your bank) that has your full financial information. It’d be great to see banks start to support this kind of thing in the U.S. (they are already moving this way with things like Visa and MasterCard shared authentication systems).

Shane • August 27, 2009 1:46 PM

This line kills me:

“[…] despite the best efforts by companies to protect data privacy, there are still individuals capable of sneaking in.”

Despite best efforts? Really? Their ‘best effort’ was swapping credit card authorization data over an open wireless network? Please.

David • August 27, 2009 2:26 PM

@Clive
A lot of people don’t like what they’re paid to do, or care about doing things correctly. Sucks to be them.

Jess • August 27, 2009 2:34 PM

Any database that stores CC#s could store a hash of them instead. How you generate those hashes and how large they are depends on what you need them for. For some uses, collision wouldn’t be a problem, particularly if your tables have other distinguishing columns. There are a few wrinkles with hashing CC#s; since they incorporate CCA-specific prefixes and check digits, they don’t span the entire set of 16-digit integers. CC# hashes certainly don’t have to be unique: do you force your customers to use a different card for every payment?

Clive, all this whining about a straightforward DB conversion reminds me of 80% of the DBAs I’ve worked with.

David • August 27, 2009 2:45 PM

@Jess
Last year I saw statistic here about the percentage of software engineers who’d use inside knowledge to break the systems they’d designed, if fired or laid off. It was almost as high as your whiner estimate for DBAs.

I’d place my figure for whiny DBAs I’ve worked with at around 50%.

Lazarus • August 27, 2009 3:33 PM

“if you’re a “hacker” you’ve already committed the ultimate sin.”

Yeah, you’re smarter than the cops.
“While being intelligent is not a felony, most societies rate it at least a misdemeanor.” RAH, “NoLL”

Matt from CT • August 27, 2009 3:33 PM

Rainbow tables are not going to help if
a proper sized hash is used. Its still a
time/memory trade off.

Get a couple valid credit cards.

Sign up for Amazon AWS.

Spin up some scientific computing instances.

What time/memory trade offs?

We may not be there quite yet, but with cloud computing, and falling prices it’s less and less of an issue.

The other alternative is to just send the problem out into your botnet of a few tens of thousands of PCs and let them crunch it on a distributed basis a la SETI.

JP • August 27, 2009 3:47 PM

Check out some of the methods used… intercepting unencrypted wireless communications, SQL injection…

2008, May – Not listed in USAO-Eastern District of New York’s archive
2008, Aug – http://www.usdoj.gov/usao/ma/Press%20Office%20-%20Press%20Release%20Files/IDTheft/Gonzalez,%20Albert%20-%20Indictment%20080508.pdf
2009, Aug – http://www.usdoj.gov/usao/nj/press/press/files/pdffiles/GonzIndictment.pdf

Gonzalez had already been in Federal custody on previous charges since May of 2008 when the Heartland breach was announced on January, 20th 2009. Some fear we may only be seeing the tip of the iceberg.

David • August 27, 2009 7:28 PM

Yeah, this isn’t magic at all. Run wireshark on any open wireless network for awhile and it’s certainly clear that users have to be responsible for what they throw into the aether to some extent. To some greater extent, if you’re designing an application that involves customer data and doesn’t at least require SSL, you’re more a part of the problem than your users.

But you have to assume that if you’re building a web application on a windows platform, your database is already forfeit.

David • August 27, 2009 7:56 PM

I can recall an incident in SF where a hotel’s server was stolen right out of the utility room midday. Just, gone. The staff was sort of upset that they had to go back to doing everything on paper, but probably not especially concerned about the potential exposure to customers.

These sorts of things happen all the time, and you don’t need a botnet to pwn an entire business’s infrastructure if you can just boost a server.

These remote attacks are only the lowest of the low hanging fruit.

Clive Robinson • August 28, 2009 7:03 AM

@ Jess,

“Clive, all this whining about a straightforward DB conversion reminds me of 80% of the DBAs I’ve worked with.”

Yup that’s my experiance too, which is why I made the point.

And is probably one of the reasons the CC Industry started to get heavy with fines and penalties.

The one thing 90% of the DBA’s I’ve had to deal with have in comon is how to yank the chain of senior managment (mainly in self defense).

Unfortunatly in many cases they have a point about not making changes to a production system, in that with large DBs there is often not enough slack in the resources sufficient to actually do proper testing.

So yes there is no logical reason why they should not make the changes just a whole host of practical ones in a usually resource starved environment.

It is also why you get that nasty little statistic about the number of businesses that fail after “data loss” in “disaster recovery”.

Such are the practical realities of life.

Sometimes it does not matter how big the carrot is, you need to use the stick to get people over certain obsticals, even if it is in their own long term interest to get over them.

Alan • August 28, 2009 9:32 AM

Bruce, I still say shred your trash. I know of someone who recently threw out old checks from a five-year-old closed account and has now been dealing with the fallout of check fraud for months.

James Van Dyke • August 28, 2009 10:03 AM

If shredding is worth an ounce of fraud prevention, turning the paper off is worth at least a pound. Sure, shredders are important, but there are at least another ten personal fraud prevention activities with greater impact on safety. If I’m an identity criminal, why would I dig past the disgusting organic detritus in your trash to get sensitive paper records that are “on the way out” when I can simply intercept sensitive mail? Your incoming financial statements are neatly identified from the outside, and if you’re still mailing outbound checks they probably go out in batches around the first few days of the month in order to make interception easy for the meth-heads. Shredding is important, but it’s way over-emphasized. Eliminate all sensitive paper first, protect the computers that are replacing the paper, and then shred (or compost, if you’re green) the sensitive paper that’s left over.

DaveC • August 28, 2009 9:53 PM

A few thoughts, having dealt with the US credit card processing industry:

The problem isn’t use of card numbers as customer IDs … aside from being illegal, or at least verboten under PCIDSS, there are better ways to do it. The problem isn’t cunning tricks like weakly reversible encryption to circumvent mandated security.

The problem is a combination of entrenched bad designs, such as settlement systems that require the merchant to keep the card number around, with entrenched bad habits, such as believing that encryption is a silver bullet.

The only way to stimulate real improvement is to subject merchants to penalties that hit them where it hurts – the bottom line.

Mark Width • September 24, 2009 7:21 PM

The basic model for electronic payments is the same as it has been for over 50 years. New security measures have been added to enhance security — signature blocks, holographic images, security codes, etc, but the basic model has not changed.

Simply adding encryption technology to the transmission of account information will slow down the cybercriminals and challenge them to a higher level of sophistication, but will not prevent it from happening. In the past, every time the security bar has been raised to a higher level, there have been people out there that have figured out ways to slip underneath. Devious minds are very clever.

From my perspective, what is needed is to change the existing model to a new system that will do more than provide protection from fraud, but prevent it from happening in the first place. Technology should then be used to implement the new model, not protect the old one.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.