Storing credit card details

Question

I have a business requirement that forces me to store a customer's full credit card details (number, name, expiry date, CVV2) for a short period of time.

Rationale: If a customer calls to order a product and their credit card is declined on the spot you are likely to lose the sale. If you take their details, thank them for the transaction and then find that the card is declined, you can phone them back and they are more likely to find another way of paying for the product. If the credit card is accepted you clear the details from the order.

I cannot change this. The existing system stores the credit card details in clear text, and in the new system I am building to replace this I am clearly not going to replicate this!

My question, then, is how I can securely store a credit card for a short period of time. I obviously want some kind of encryption, but what's the best way to do this?

Environment: C#, WinForms, SQL-Server.

Solution 1

Basically avoid by all means taking the responsiblity to save the CC details on your side, however I can assume you are using a thirdparty service to do your transaction such as PayPal/Verisign or whatever, most of them have API's that enables you to save CC credentials at their side, and they give you back a key that you can then use later to complete or initiate transactions, so they take care of the hard part, while all what you have to do is store this string key in your DB.

Solution 2

Andrew, you need to understand the PCI-DSS, no small task. Personally, I find it extremely vague but here is what I understand.

First off, from the scenario you describe I would attempt to authorize the card for the full amount and then if that failed I would store the customer's information (but not the cardholder data) so someone could contact the user. Where I use to work some of our customers would only charge $1.00 and then void the transaction immediately, just to make sure the card was valid. They would then process all orders manually.

Where you will need to store the number is on a successful authorization. The only number you need then is the credit card number and the transaction code (at least with every gateway I have ever worked with).

The standard, last time I looked at it, is not specific on encryption algorithms but instead makes it clear it should be currently unbreakable encryption.

Now, one thing you cannot do is store the CCV subsequent to authorization. My understanding is that you can store it prior to authorization but I could never get anyone that would put that in writing. Basically, you authorize the card, you better wipe it.

And it is not illegal at this point but if you get nailed they will bring the hammer down on you. They have within their authority to level heavy fines against you, but it seems like what they usually do is put you in remediation. If you don't comply I don't know what happens because everyone I have heard this happening to complied. But then they really go up your booty with a microscope.

Ultimately, I believe their only stick they really have is to prevent you from accepting credit cards. Most merchants I have worked with were scared to death of exactly that.

Solution 3

I don't believe it's actually illegal to store CVV info (in the sense that it's against any law), but it does violate Payment Card Industry rules, and they could impose any number of different sanctions. So, your requirements could actually result in you not being able to accept credit cards ;-(

Solution 4

If you just want to store the string for a short period of time in memory, you can take a look at System.Security.SecureString.

Taken from this answer:

SecureString values are stored encrypted (obfuscated, rather), but most importantly, they are never swapped to disk and can be disposed of immediately when you're done with them.

They're tricky to use because you can only build them one character at a time (to encourage you to build them by capturing keystrokes as the user types their password), and require three lines of code to recover and then wipe their plain text, but when used properly they can make a program more secure by avoiding the virtual-memory vulnerability.

At the end of the example the SecureString is converted into a regular managed string, which makes it vulnerable again (be sure to use the try-catch-finally pattern to Zero the string after you're done with it). SecureString's use is in reducing the surface-area of attack by limiting the number of copies the Garbage Collector will make of the value, and reducing the likelihood of being written to the swap file.

// Make a SecureString
SecureString sPassphrase = new SecureString();
Console.WriteLine("Please enter your passphrase");
ConsoleKeyInfo input = Console.ReadKey(true);
while (input.Key != ConsoleKey.Enter)
{
   sPassphrase.AppendChar(input.KeyChar);
   Console.Write('*');
   input = Console.ReadKey(true);
}
sPassphrase.MakeReadOnly();

// Recover plaintext from a SecureString
// Marshal is in the System.Runtime.InteropServices namespace
try {
   IntPtr ptrPassphrase = Marshal.SecureStringToBSTR(sPassphrase);
   string uPassphrase = Marshal.PtrToStringUni(ptrPassphrase);
   // ... use the string ...
}
catch {
   // error handling
} 
finally {
   Marshal.ZeroFreeBSTR(ptrPassphrase);
}

Solution 5

If you are going to store credit card information you really need to be PCI compliant or you're just asking for trouble.

Having said that look at the cell level encryption available in SQL Server 2005 and above. Coincidentally :) I have recently given a presentation with T-SQL samples on encryption with SQL Server 2005/2008 available here: http://moss.bennettadelson.com/Lists/Events/Attachments/9/June2008.zip (Link location updated December 23, 2008)

View more solutions

Comments

[MrChrister]

This is correct. The term he is looking for with the card processor is Authorizing, this confirms the funds but does not capture them.

[Michael Burr]

"Most merchants I have worked with were scared to death of exactly that". There are few things scarier to a business than, "we're taking away your ability to get money".

[E_the_Shy]

It's also against the scheme rules to charge $1.00 just to see if the card is valid. You are only allowed to charge if you're providing a service or good.

[aruno]

so a securestring has no place in a web environment then?

[JoshBerke]

You definelty need to be PCI compliant and your probally better off relying upon a third party to process the credit cards.

[Rob]

In addition to revoking your acceptance, the main card schemes can levy some pretty large fines, which tend to put the icing on the cake for a lot of merchants.

[Dean]

He mentions completing transactions which would be 'Authorizing'. But he's also talking about a method for doing all kinds of transactions from one-offs to variable recurring transactions all with using the key from your third-party payment provider who is storing the customers billing details so that you don't have to.

[eozzy]

Not true, you can be SAQ-D PCI compliant these days for just about $800/m there're many virtual dedicated solutions available. But ofcourse, you still have to do proper encryption and key management yourself.

[ClearCrescendo]

I have read that the state of Nevada requires PCI compliance by law so it would only be illegal there, however in other sates your payment service provider will step in with their own version of a fine, so best to get into the straightjacket voluntarily anyway.