No, PCI/DSS is similar to the Better Business Bureau: many people think its an official (i.e., government mandated agency/law) but it's not. Many merchant account companies require it, but it's entirely possible to find a merchant account that does not require you to be PCI/DSS compliant.
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.
It all depends on your transaction volume. If you don't run that many transactions then all you have to do is fill out a form saying you're complying.
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.
Definitely. I also believe you get a discount per transaction if you're compliant.
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.
This is why I never use ATM debit cards outside of an ATM (e.g. for groceries) I've read reports of software along the path of the transaction caching PINs. Throw this unauthorized caching concern into the murky waters of bank liability for fradulent transactions, and I would go to an ATM (ideally one that has anti-skimming provisions) and withdraw cash before trying to pay with ATM at the POS terminal.
"Now it's emerged that those very same confirmation emails contain a web link - ironically intended to direct customers to Argos's security page - which contains the customer's full name, address and credit-card details in the URL itself."
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.
Perhaps there's a role for a site that names-and-shames poorly implemented ecommerce sites. I've recently been asked to enter my visa into a site without https.
There shouldn't be any excuse for this sort of thing now.
I really enjoy ecommerce development and have spent the last 4 years professionally doing something related to it.
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.
What amazes me is that there are services like paypal, google checkout and others that can handle all this for the vendor. If someone wanted to set up in an afternoon they could: just use a pre-developed card and protect yourself from fraud too.
Even quick time-to-market is not an excuse any more.
Some developer has clearly mis-understood the 'stateless' part of HTTP. The protocol is stateless, but the resources are NOT stateless. You don't have to and shouldn't send all of the information your service needs through the protocol; all you need to send is sufficient information to fully identify the resource you're working with. In this case, that would be the customer id number, which is your key into a database that has the real customer information.
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.
You wouldn't want to encrypt the CC number with the security code. It makes it easy to discover the security code if you can get the CC number, which isn't so hard to do. In fact, unless I'm mistaken, it's not allowed to use the CVV for anything. But basically, if someone is able to get the CC number, then it's merely a quick check of the possible security codes, which is small in number. Granted, I understand why you want your credit card number encrypted using user encryption, but instead of using the CVV, you might try using something else, like their password.
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.
Good points. I hadn't thought of the potential to brute-force the CCV based on having the encrypted and unencrypted CC, but I had only spent a minute thinking about it. Perhaps in minute #2 I would have realized that. I was thinking of using the CCV in combination with other user data as the key anyway; it was just a piece of data that wouldn't be stored in my system, so that the data in my system wouldn't be sufficient to decrypt the CC.
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.
> To brute force the CCV, you do need the clear text CC.
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.
Focusing on your second paragraph, yeah, all that would work fine. The key is not to store the CVV or use it. The degree at which you encrypt data is dependent on your needs. All that encryption you are talking about sounds good, but I'd question why you need the CC then? Indeed, encrypting it with the users password presents another obstacle should the user forget his password.
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. It's not allowed. However, you usually don't need to send over the CVV code to make a transaction if previous transactions have been made to that mid.
At the same time, Visa and MC make up their own rules, and Amazon, PayPal, and others could have their own agreements.
Ah the subsequent-transactions thing must be it then. I know I've only had to enter my CVV the first time I've used most online shopping sites, so I assumed they just stored it.
At some point the user has to fill out a form and provide the CCV. I happen to log form fields in addition to GET urls, so the CCV would wind up in my log if I didn't filter it out.
As the article notes, the offending e-mail also contained a link that included various sensitive data. Anyone following that link hits your server log, leaves the link in their browser history, etc.
In the US, isn't this exactly the sort of data that, when a bank or other entity exposes it in a "breach" (lost employee laptop), is required to be reported to the government? My understanding of this law is common knowledge, not lawyerly and knowledgeable.
Maybe if you dribble it out, on purpose, it's not considered a breach.
Wrr, websites that do this irritate the living hell out of me. It's only after you've ordered or signed up that you discover that they've decided to pollute your inbox and history like this, leaving you with the job of cleaning up properly.
