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?