Hacker News Reader

Comment by DougWebb | Hacker News Reader

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.

View on HN

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.

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.

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.

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

It's pretty standard among ecommerce companies to store the CVV code though, isn't it? Amazon, PayPal, and Google Checkout all do.

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.

Indeed, you don't need to do it ever. I don't take CVV codes, nor does 37 Signals.

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.

> filter those codes out of the log

Why would there be creditcard data in you HTTP log?

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.

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.

Reply on news.ycombinator.com