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.
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.
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.
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.
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.
It might be a different story if the system required users to also enter in data like the exact customer first/last name.
http://www.wired.com/2015/11/samy-kamkar-10-dollar-tool-can-...
Beyond that, most things display first four & last four, so you can probably assume they have that too.
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.
I haven't read Brian's post though because I'm getting 503 errors atm.
Most do just tokenize with a third party processing company though.
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.
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.
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.
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.
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...
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
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.
(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.)