Not downvoting, but the number of corporations storing credit card information would terrify you.

Seen it at former jobs as a dba, helped to change that at some, and its among the top ten list of things to check when I start at new one.

If they got caught doing that, both VISA and Mastercard will essentially ban them. At least if it is an insecure as you make it sound and they haven't met PCI DSS.

So instead of storing known gotcha cards in these databases, a likely better solution would be to discontinue the use of these databases.

Most major retailers don't store credit card numbers. The full information never leaves the terminal, and is discarded when the transaction is complete.

PS - Thanks for "Not downvoting" but why would you anyway? Nothing I said contradicts anything you've said. I said large retailers aren't storing CC information. Are you claiming they do? If so, name names.

There are plenty of small "mom & pop" sites out there that store full credit card info, in plain text, in unsecured databases, in blatant disregard of card company policies. They go with the thinking that it costs to much to implement security and nothing will ever happen to us. We hear about the big breaches on the news, but I would bet for every big breach we hear about on the news there are thousands of smaller breaches that don't get recognized.

For example, about two years ago I had a property management company ask me to build out a site to handle rent payments for them. They wanted to store and have access to the full credit card numbers to manually process transactions for failed or late payments. When I told them they were not allowed to do that they terminated the contract with me. I know they went on to hire a developer to build out a site for them and store credit card numbers. While I don't know if they are still doing it, it did happen for an extensive period of time.

That was also the case for a number of ACH portal softwares sold alongside retail POS suites in the 2000s. Instead of temporary storage until batching, full transaction details were held permanently by default.

At any time, anyone with access to a payment terminal who knew where to look could process transactions manually from these records. They could have double charged and skimmed, done reversals for a cut, or copied and sold customer profiles with CC numbers. These were BSA products marketed to small and medium sized businesses, so no one questioned compliance.

I prefer to put consequences in terms of money.

That said, on the flip side, because of things like "Dual Control" the PCI DSS is physically impossible for some small companies to abide by. In the past we dealt with credit cards and had a few audits, and they admitted that many of the points are aimed at companies that don't consist of just two people.

Also, look at it from their POV. In a normal course of business a lot of these mom and pops probably already are storing credit card information on paper and/or in word documents. So you're saying the system you build for them is going to be, in some ways, less useful than their current ad-hoc system.

My mom & pop tax guy emails me my tax return as an encrypted pdf, with the password being... the last 4 digits of my SSN.

Oh there is no question if you bring paper records in to the mix there are enormous opportunities. I worked at a mom & pop restaurant for several years. In the attic of the restaurant were stacks of boxes with credit card receipts dating back to the mid-80s at least. While the chances of many of these cards being valid now are significantly reduced, there is always that slight chance. I have a credit card from the early 90s that the number has not changed (kind of nice in a way as I can recite the number by memory now).

On the flip side though, to some extent, I would consider these records safer than a website. At least to gain access to these records you would have to physically enter the building, climb in the attic, sift through hundreds of boxes, gather the info you want, and then leave. This would also require you be in the general location of the building and have knowledge of the records being there. Hacking a website database from across the globe is a whole lot easier, so you I would say that their existing paper system is more secure to a degree.

You seem to think VISA and Mastercard have the desire to reduce fraud, they dont. They have a desire to reduce their liability.

PCI DSS is largely a marketing ploy, and way for them to shift liability from banks and the network to the merchants.

As a security standard PCI DSS is terrible

Further storing card numbers is not a violation of PCI-DSS, it would be impossible for them require that as reoccurring billing, auto-pay, etc have a requirement for the PAN to be stored.

Look at Amazon, it stores my card number, in full, so I can checkout with out having to reenter it every time

While I do not want to name names, I have worked for a very large retailer that everyone in the US would know that stored credit card information for quite a long time. They are large enough to do large chunks of their credit card processing themselves, instead of having a third party processor. They even have their own set of cards that they process themselves. It might have changed in the last few years though.

Either way, they did take PCI DSS seriously, and passed audits: dual control requirements for keys and all that. Still, accounting could print reports with many credit card numbers, although it was all logged and relatively well tracked.

I have not worked in a lot of big retailers though, but I have seen others that featured searching for a missing receipt by credit cards number, or refunds to the original CC way past the window where a processor can just reverse a charge. There's also online retailers, that definitely remember your credit card number. So I suspect there are plenty of retailers that at least have historically kept CC numbers, whether being PCI compliant or not is another matter entirely.

I worked at a place ~10 years ago that had full PCI certification, you only have to be compliant if your the one doing the processing. We had loads of 3rd party clients using one of the customer facing applications that's stored the card details and potentially the cv2 numbers in the clear. They then sent them to us to batch process a couple of times a day. If their connection crapped out, they sent them again later. I distinctly remember reprocessing card details of transactions that had happened more than 2 weeks prior. Credit card numbers are incredibly easy to generate too, the check digit routine is well known, and you can just try the other details randomly for small amounts till you hit jackpot.

I haven't read Brian's post though because I'm getting 503 errors atm.

You can't really "try the other details randomly for small amounts till you hit jackpot" - merchants who do that (or if their service allows others to do that) get simply kicked out of the network, pretty much every acquirer will monitor your rejection rates closely.

Storing the a cryptographic hash of the credit card number would allow for searching for receipts by credit card number without storing the actual credit card number.

Credit card numbers aren't nearly long enough to prevent a brute force attack against anything of the nature.

I think it partly depends on how many customers the store has. If it's a mom-and-pop place with a salt on their hash, attackers would get much less "profit" out of their search.

Anywho, just going to engage in some half-assed napkin-math to explore the idea:

Card numbers: 6 digits for institution and 9 for the customer and 1 for checksum. Let's assume merely 20 big issuers "worth attacking". The possibility-space to search is then (20 * 9^10), or ~70 million.

Suppose that--by design--it takes 2 seconds to compute the hash. Covering the whole range would take ~4420 years. That's... not a very comforting margin.

Perhaps you could hash the credit-card along with the year-month in which the purchase occurred, but attackers probably aren't interested in >12 month old cards, so that's only a small 12x slowdown there.

If the point of storing them is to search for credit card matches, I don't see how you could salt them in any useful way.

Beyond that, most things display first four & last four, so you can probably assume they have that too.

> I don't see how you could salt them in any useful way

Yes, I agree. Even two seconds of waiting for your search is a little on the high side, UI-wise.

> Beyond that, most things display first four & last four

My impression is that "only last four" is the most-common.

Are card numbers perfectly random? I mean, excluding the industry/company identifier and the check digit?

Whoops, it seems I kept editing without seeing your reply. Sorry, bad habit of mine. I don't know how random the customer-portion is, but I assume/hope it is. I put some napkin-math in, but AFACT javawizard's right about the basic issue.

It might be a different story if the system required users to also enter in data like the exact customer first/last name.

There's a way to generate subsequent AMEX Card numbers once the card is deactivated[0]

http://www.wired.com/2015/11/samy-kamkar-10-dollar-tool-can-...

The problem is not that the merchant stores a number, but that all the merchants store the same number. Why not just use OAuth?

~8 years ago, I worked at one of the largest retailers in North America (top 5). Credit card numbers were absolutely stored in logs accessible to me (an on-the-floor employee who processes returns, etc.). It was useful as I could use them to find purchases if someone lost their receipt but had the credit card. It was also incredibly insecure. I believe they've changed it since then, but it would not surprise me at all if other retailers were in the same boat.

Agreed, the downvote should be used for content you find inappropriate or adds nothing to the discussion. A dissenting opinion that is on topic should not be downvoted.

Downvoting to signal disagreement is allowed, and you can't stop it in practical terms anyway, so accepting that it is a thing is pretty useful.

Getting a little offtopic, but regarding your PS: I dont know, I just often see someone assume that someone replying to them (when they are being downvoted by others) assume that the person has negative intent and is part of the downvoting spree.

I would much rather engage in some discussion even if their opinion is honestly held than downvote someone I disagree with. If someone is a shill or not listening to reason on the other hand...

I've worked at shops that don't meet PCI DSS. It's a sticking point, and we WANT to comply, but also don't want to spend the money to comply, and the processor wants us to comply too, but they'd rather have our business than give us the boot for not meeting PCI DSS.

A lot of companies do store full card numbers. Not usually physical retail stores, but for online companies it's not /that/ unusual.

Most do just tokenize with a third party processing company though.

This would be a PCI violation, so if it's common, then someone has some calls to make.

I'm a stickler about enforcing data retention (and non-retention) standards where I work. We never store any credit card information. That would be an outrageous liability.

Storing the PAN is not a "PCI violation". It's not best practice, for sure, and you then have an obligation to secure your systems much more thoroughly, but you can do it. "Payment brand rules allow for the storage of primary account number (PAN), expiration date, cardholder name, and service code." https://www.pcisecuritystandards.org/documents/SAQ_InstrGuid...

(There are other types of data you can NEVER store (also described in the above document) like the CVV or PIN code, which is perhaps what you meant.)

The person I was responding to just said "credit card information". CVV, PIN, and CC # are all verboten.

Sorry, you are wrong about the CC# (PAN) Read what I linked to again.

Oops, you're right.

Swiper skimming might be an issue as well, but didn't some of the largest breaches include stored credit card data? Washington Post says credit and debit card information was included in the Target breach.

https://www.washingtonpost.com/business/economy/target-says-...

I said nothing about swiper skimming.

What I said was:

> What the criminals are targeting is the card terminals themselves. Meaning when you swipe your card, as the transaction is being conducted they take a copy of the information and re-transmit it to a host somewhere they control (or to a C&C machine on that network, which they then exfiltrate somehow).

Which is accurate:

> The apparent credit and debit card breach uncovered last week at Home Depot was aided in part by a new variant of the malicious software program that stole card account data from cash registers at Target last December, according to sources close to the investigation.

So malware was intercepting the raw CC information inside the card terminal on its way to the payment processor upstream. This allowed them to remotely infect every single Target store in the country, and steal information without setting foot there.

http://krebsonsecurity.com/2014/09/home-depot-hit-by-same-ma...

Ah, the distinction being that it wasn't stolen in a single bulk breach or via a device placed between the card and the scanner. Fair enough.

Yep, lots of these point-of-sale machines are (still!) running XP Embedded which is, AIUI, pretty heavily targeted. Apparently -- but not surprisingly -- they aren't updated all that much so they're pretty susceptible to being compromised.

Yes, for point-of-sale exploits, this would not work. But certainly there are companies that store CC information. Every time I go to Amazon, I don't re-input my cc info. They must be storing it somewhere?

As for buying it back, see my comment about LE not needing to make such purchases for this to work. And if the CC companies know about the fake numbers, the process of verifying that the number works, would itself, inform of the breach.

> Most large retailers only store the full credit card information for seconds while they process the transaction, when the transaction is complete it is discarded.

Couldn't work around that by having some device that attaches to a randomly selected POS terminal, and then executes a series of dummy transactions using thousands of "canary cards" that were assigned to the store?

They could perhaps set this up with the credit cards companies so any use of the canary cards are automatically flagged when they're used outside of the store that was issued them.

Could very well work, only you would need cooperation with one or more major payment processors/card issuers.

The way it would work is that shops are given hobeypot cards and asked to use them weekly for dummy payments. The moment one of these cards show up anywhere else than the shop it was sent to you can expect the shop has been hacked.

It is not failsafe and you will have to wait until a batch with this card is stolen before this tells you where.

>Plus even if you could get your "gotcha" credit cards into the criminal's hands, the chance of law enforcement buying one back is tiny, since the stolen batch is mixed with other cards, and only then a small sub-set is sold (since they verify if the card is still active, and meets other conditions).

You wouldn't need law enforcement to buy it. You just need the bank to watch for a transaction on any of these cards that's not from the merchant it was assigned to.