5 ms·

Argos email receipts contain your Card No. CCV, Name and Address

53 points by Roridge 17y ago

DougWebb 17y ago
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.
- _delirium 17y ago
  It's pretty standard among ecommerce companies to store the CVV code though, isn't it? Amazon, PayPal, and Google Checkout all do.
  - jasonlotito 17y ago
    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.
    - cryptnoob 17y ago
      Indeed, you don't need to do it ever. I don't take CVV codes, nor does 37 Signals.
    - _delirium 17y ago
      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.
- Roridge 17y ago
  I object to your use of the word "developer" in that sentence ;) 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.
- mseebach 17y ago
  > filter those codes out of the log Why would there be creditcard data in you HTTP log?
  - Silhouette 17y ago
    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.
  - DougWebb 17y ago
    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.
- jasonlotito 17y ago
  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.
  - DougWebb 17y ago
    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.
mootothemax 17y ago
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.
acg 17y ago
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.
- leftnode 17y ago
  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.
  - acg 17y ago
    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.
ig1 17y ago
How can this possibly be within PCI DSS compliance rules ? - do they not apply to everyone taking Mastercard/visa ?
- tbgvi 17y ago
  It isn't. Storing CVV is not allowed under any circumstances.
- leftnode 17y ago
  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.
  - tbgvi 17y ago
    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.
    - leftnode 17y ago
      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.
- wallflower 17y ago
deleted 17y ago
[deleted]
wendroid 17y ago
> Argos said that it "takes the security of its customers’ data extremely seriously The straightness of face or otherwise was not reported
jaxc 17y ago
"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. Edited for typos and readibility.
nfnaaron 17y ago
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.

53 points by Roridge 17y ago

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.

_delirium 17y ago
It's pretty standard among ecommerce companies to store the CVV code though, isn't it? Amazon, PayPal, and Google Checkout all do.
- jasonlotito 17y ago
  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.
  - cryptnoob 17y ago
    Indeed, you don't need to do it ever. I don't take CVV codes, nor does 37 Signals.
  - _delirium 17y ago
    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.
Roridge 17y ago
I object to your use of the word "developer" in that sentence ;) 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.
mseebach 17y ago
> filter those codes out of the log Why would there be creditcard data in you HTTP log?
- Silhouette 17y ago
  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.
- DougWebb 17y ago
  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.
jasonlotito 17y ago
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.
- DougWebb 17y ago
  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.

mootothemax 17y ago

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.

acg 17y ago

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.

leftnode 17y ago
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.
- acg 17y ago
  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.

ig1 17y ago

How can this possibly be within PCI DSS compliance rules ? - do they not apply to everyone taking Mastercard/visa ?

tbgvi 17y ago
It isn't. Storing CVV is not allowed under any circumstances.
leftnode 17y ago
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.
- tbgvi 17y ago
  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.
  - leftnode 17y ago
    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.
wallflower 17y ago

deleted 17y ago

[deleted]

wendroid 17y ago

> Argos said that it "takes the security of its customers’ data extremely seriously The straightness of face or otherwise was not reported

jaxc 17y ago

"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. Edited for typos and readibility.

nfnaaron 17y ago

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.