Hacker News Reader

Comment by TheGRS | Hacker News Reader

Maybe I'm a little ignorant on how/why companies store this sort of info. Someone at work informed me that Target storing CC numbers at least made sense when you needed to make a return. But at a Sonic Drive-In? I'm not returning my burger+shake combo.

What is possessing Sonic to keep the number any longer than the period it takes to receive money from the CC company? And why is this period any longer than the 20 or so seconds it takes to process the card at a machine? Are all of these magnetic-only or do they store CC numbers with chip cards as well?

View on HN

I don't believe in this case the hack targeted any cards held on file, as the article suggests it may have been a hack of the POS software system that would allow the thieves to copy the info from the magnetic strip as it was captured in real-time and then clone the card.

> What is possessing Sonic to keep the number

They don't. From the article:

"Malicious hackers typically steal credit card data from organizations that accept cards by hacking into point-of-sale systems remotely and seeding those systems with malicious software that can copy account data stored on a card’s magnetic stripe. Thieves can use that data to clone the cards and then use the counterfeits to buy high-priced merchandise from electronics stores and big box retailers."

"The last known major card breach involving a large nationwide fast-food chain impacted more than a thousand Wendy’s locations and persisted for almost nine months after it was first disclosed here. The Wendy’s breach was extremely costly for card-issuing banks and credit unions, which were forced to continuously re-issue customer cards that kept getting re-compromised every time their customers went back to eat at another Wendy’s."

That provides an interesting lesson for vendors doing CC transactions: card compromise does not impact repeat business, so don't worry about breaches.

That's assuming the consumers were informed about the source of the compromise.

To this point, my bank replaced my card due to a breach that they refused to disclose to me. I'd like to know the source so I can avoid shopping there, but cannot.

Target wasn't storing credit cards. They installed spyware onto the POS systems, and the CC numbers were not stored in memory on the actual register. So there was a point in time that they could be pulled from system memory. There was an in-depth analysis I'm struggling to find at the moment. But Krebs shines a bit more light on it.

https://krebsonsecurity.com/2014/02/target-hackers-broke-in-...

While Target does store transaction information, they don't store the actual credit card info. That's why you need to provide the physical credit card to do a return, or they give you store credit.

> ... Target storing CC numbers at least made sense when you needed to make a return.

This is why I think the merchant processors should be instead be doing this by some kind of transaction ID. I.e. send the refund amount to the processor with the transaction ID instead of sending a new transaction to the card. It's more secure, and less error prone since you could build in checks for the amount returned and other such bits.

Every Payment processing system I have worked on did work that way, I did not need the card number to issue a refund only the AUTH Code

It is a good way to track customer's buying habits. eg how many people go weekly, or to different stores, or buy same products etc. eg HomeDepot tracks credit card back to userid https://consumerist.com/2013/01/16/home-depot-sort-of-explai...

For that it should be good enough to just store the first 6 digits and the last 4 digits of the card number. You might occasionally get two different customers whose first 6/last 4 are the same but it should not happen often enough to be a significant issue.

If even that small risk of conflating two different customers is too high, you could go with a hash of the credit card number.

If you go with the hash, then don't ALSO store first 6/last 4. A typical credit card number is 16 digits, and one of those is a check digit. If someone gets a hold of the hash, and first 6/last 4, then there are only 100 000 possible values for the missing 6 digits (10^5, not 10^6, because for any guess for 5 of the digits there is only one possible 6th digit that will make the checksum work). Unless you use a very very slow hash function, brute forcing 100 000 possibilities will be quick.

The first four digits are pretty generic. They tell you who issued the card. Many people will have the same first four digits. Maybe the second set of four and the last set of four would be better?

Usually the first four is the issuer and whatever numbers signify the specific type of card. The next set is the bank, I think. The third set is, as I recall, the account number, and the last numbers equate to your routing number.

Actually, just the last eight digits should be adequate. Hash them with a salt based on the last name and collisions are very, very unlikely. Don't store them at all, just store the hashes.

I can’t tell if you are playing, but by storing the most unique part of the credit card with last name you are not reducing the desirability of the target much.

You don't store the name. You use the name to generate the salt and hash the results. You only store the hashes.

You are still doing a near lossless transformation of the unique part of the credit card and name as one of your goals is zero (minimized) hash collisions. The character set and length of the input plus reasonable assumptions about the salt and hash make it very likely "reversible" using rainbow tables or other brute force techniques.

Choose metadata that doesn't have such high financial value. Additionally, it's been years since I've been involved in e-commerce and the details are now foggy, but if I recall storing those addition credit card digits, even transformed, will prevent you from achieving the industrial certifications.

This is what hashing is for.

RSA sells a very nice hardware device that will tokenize credit cards such that it's safe to store the tokenized value _AND_ you can detokenize it in order to charge (or refund) the card.

If there is a fingernail in my milkshake you can bet I will get a refund. That's still no excuse to be storing this information because as pointed out they should only need the transaction ID to issue refunds.

Ignoring batch processing, they're also keeping this information in case of fraud issues, refunds, customer tracking for marketing purposes, etc. Even with PCI compliance you can store card information. You only can't store the CCV number. If your storing methods uses easy to circumvent encryption, then, ta-da, the hackers get all the credit cards.

Reply on news.ycombinator.com