4 ms·

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 sh

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.

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