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-...