Argos email receipts contain your Card No. CCV, Name and Address
pcpro.co.uk
pcpro.co.uk
Some people say PCI/DSS compliance is a scam, because you generally have to pay someone to say you're PCI/DSS compliant, officially, if I remember correctly.
If your transaction volume is high, for example let's say Walmart, then the level of scrutiny goes way up. There is the option of not complying with PCI, but Visa and MasterCard wouldn't authorize transactions for them anymore. In a case like that there's a pretty big monetary incentive to comply.
PCI isn't perfect, that's for sure, but its probably better than nothing.
We had to become compliant for the merchant we use, and because we don't do a lot of transactions, it was only $80 a year. Small price to pay, I think, to keep my ass covered somewhat.
I suppose I came off as not liking PCI/DSS. I do like it, just wanted to clarify some things about it.
I'm speechless... I may not understand PCI compliance fully but surely anyone with any brains could see that is a bad idea. I mean why would you reveal someone's credit card details in the URL. Not to mention emailing it. This beggars belief.
Edited for typos and readibility.
There shouldn't be any excuse for this sort of thing now.
It's flat out amazing the poor security standards in the industry.
"Hey just email me an Excel spreadsheet of customer's credit card numbers, I need to charge them all," is not unheard of.
I know there are places where security is of high importance, but I've seen some places where it's really poor.
One of the problems is ease of entrance. In an afternoon, you can get a website set up, sell products, and take credit cards (along with other personal information) with absolutely no knowledge of how to do anything properly. In all honesty, that barrier for entry needs to be much much higher.
Even quick time-to-market is not an excuse any more.
Oh, and DON'T STORE UNENCRYPTED CC NUMBERS, AND NEVER STORE THE SECURITY CODE. That should be so obvious. If I were building a system like this, and I was required to store the CC number at all (which I'd prefer not too but many retailers do it) I'd encrypt it using the security code, and I'd modify my http logs to filter those codes out of the log. That way I couldn't decrypt the CC number without asking for the code, and I'd never have the code stored anyplace on my system.
At the same time, Visa and MC make up their own rules, and Amazon, PayPal, and others could have their own agreements.
I totally agree with you, as a developer I would have strongly objected to storing peoples CCV number to start with.
Generally, this is shocking, and backs up what so many in the UK claim that there really isn't enough good developers.
Why would there be creditcard data in you HTTP log?
Storing the CC number in an encrypted format is fine, however. You want to be able to retrieve that information at a later date, after all. Should a user want to make another purchase, they really shouldn't have to enter their CVV all over again.
Granted, this all assumes you have to handle this. An even safer way is to use the gateways capabilities. Many of the option to create rebillable transactions. You send over the specifics, and they handle the rebilling for you, and you don't have to store anything of the users.
To brute force the CCV, you do need the clear text CC. You wouldn't get that from me because I wouldn't be storing it. If you got it from someplace else, there's a good chance the game is up already. But you're right; if my database got stolen and combined with some other data sources, the customer's info could be matched up to get both cleartext and encrypted versions of the CC, and if the person doing this knows my encryption algorithm (a disgruntled developer, for example) they could brute-force the CCV. Maybe encrypting the other user data is appropriate as well, based on the user's password which also would not be stored anywhere in my system. Now, you need to brute-force the password just to get the name/address info from my database records, then you need to match that against someone else's cleartext CC numbers, then finally you can brute-force CCVs from my encrypted CC if you know my algorithm and what I'm using for keys. That's a fairly high barrier.
For what it's worth, my company does do CC transactions, and we do use a service provider for this which I 100% agreed with. Our user's address and payment info never touches our system at all; we send them off to the payment processor, and the payment processor sends us a token to tell us the transaction went through ok.
Getting someone to re-enter credit card data isn't as bad as many might have you think. People are used to it. They know it. In many ways, it makes them feel better.
Of course, let's not get started on another problem: A user tries to make a purchase with a credit card that has already been used on the system for another account. Do you let the user make the purchase? Do you deny him that ability?
Oh, the usability and privacy implications for that is insane.
No you don't; the ciphertext will do. There CCV codes are three or four digits, so you have 1,000 or 10,000 keys to try. Try all of them. If the plaintext is encoded in ASCII, then throw out all the ones where the plaintext isn't a number. There will very likely only be one left, and that's the credit card number.
If the plaintext CC number is encoded as a binary number (does anyone do this?), filter for (a) proper length in decimal; (b) number is positive (if stored signed); (c) check digit verifies; (d) card type code (first few digits) are sane; if you still have more than one, (e) bank code (next few digits) is sane.
And naturally, once you have the CC number, you know which key got you it. So you have the CCV as well.
Maybe if you dribble it out, on purpose, it's not considered a breach.
The straightness of face or otherwise was not reported