3 ms·

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 a

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.

jasonlotito 17y ago
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.
derobert 17y ago
> 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.

jasonlotito 17y ago

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.

derobert 17y ago

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