Credit card storage

Question

I have a business requirement that forces me to store customer credit card information (number, name, expiration date, CVV2) for a short period of time.

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

I can’t change that. The existing system stores credit card information in clear text, and in the new system I create to replace this, I obviously am not going to repeat it!

So my question is how can I safely 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.

Answer 1

Basically, avoid the responsibility of storing CC data on your side, however I can assume that you are using a third-party service to complete your transaction, such as PayPal / Verisign or something else, most of them have an API that allows you to save the CC credentials on their side, and they will return a key to you, which you can then use later to complete or initiate transactions, so they will take care of the difficult part, while all you have to do is save this string key in your I have a database.

Answer 2

I don’t think it’s actually illegal to store CVV information (in the sense that it is against any law), but it violates the rules of the payment card industry and they can impose any number of different sanctions. Thus, your requirements may result in you being unable to accept credit cards; - (

Answer 3

Andrew, you need to understand PCI-DSS - this is a small task. Personally, I find this extremely vague, but here's what I understand.

Firstly, from the scenario you described, I will try to authorize the card for the full amount, and then if this does not succeed, I will store information about the client (but not the data of the card holder) so that someone can contact the user. Where I will work, some of our customers will only charge $ 1, and then immediately cancel the transaction to make sure the card is valid. Then they will process all orders manually.

If you need to save the number, you will receive a successful permit. The only number you need is a credit card number and a transaction code (at least with every gateway I've ever worked with).

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

Now, one thing you cannot do is save the CCV after authorization. I understand that you can save it until authorization, but I can never attract anyone to write it in writing. Basically, you authorize a card, you better erase it.

And this is not illegal at the moment, but if you are nailed, they will bring you a hammer. They may impose heavy fines on you within their powers, but it looks like they usually do, which means that you are correcting. If you don’t comply, I don’t know what is happening, because everything I heard is happening. But then they really raise your prey with a microscope.

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

Answer 4

If you are going to store credit card information, you really need to be PCI compatible or you just ask for problems.

Having said that, take a look at the cell level encryption available in SQL Server 2005 and later. Coincidence :) Recently, I presented a presentation with T-SQL samples for encryption with SQL Server 2005/2008, available here: http://moss.bennettadelson.com/Lists/Events/Attachments/9/June2008.zip (link location updated 23 December 2008)

Answer 5

If you want to keep a 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 (rather confusing), but most importantly, they never change to disk and can be deleted immediately when you are done with them.

They are difficult to use, because you can create them only one character at a time (to encourage you to create them by capturing keystrokes when the user enters their password) and require the restoration of three lines of code, and then destroy their plain text, but if correctly When used, they can make the program more secure by avoiding the vulnerability of virtual memory.

At the end of the example, SecureString is converted to a regular managed string, which makes it vulnerable again (be sure to use the try-catch-finally pattern for the null string after you finish with it). Using SecureString is to reduce the attack area by limiting the number of copies that the garbage collector collects and reduces the likelihood of writing 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); } 

Answer 6

It costs somewhere around $ 30,000 to become properly compatible and be able to do such things. You are better off using a third-party payment service. Personally, I recommend Element Express, and they have a "Hosted" solution that bypasses PCI-DSS PAPDB. I had to convert this to my own applications, even point of sale machines! This is a big pain, but we are a small company.

http://www.elementps.com/software-providers/our-security-edge/hosted-payments/PA-DSS-Certification-vs-Elements-Hosted-Payments/

In the link above there is some good information about the costs associated with obtaining compliance. We had clients who asked us to store credit card numbers, and we will not do this because we can be fined. Not good. Do not open yourself up to responsibility.

Edit:

In addition, if you decide to store credit card information, you definitely need to consider the encryption forms that you intend to use. Symmetric? Asymmetric?

If you perform symmetric encryption (Passkey), you will find serious security vulnerabilities if the server (site) that has the key (necessary for encryption) is compromised in any way. Remember that even compiled code will not hide the text key.

If you use asymmetric encryption (public / private keypairs), you run into some additional problems, but if the primary open server is in danger, they will only have the public key, and if they also gain access to your database .. they won ' t be able to decrpyt content.

The question is where do you store the private key? You have someone paste it from local computers when you start admin functions. You have a separate application that runs on the desktop to view orders, etc.

There are many things to consider.

Final note. Use a payment gateway (Element Express, Authorize.NET, Paypal, etc.) and do not store credit card information locally .: P

Here is a link about using X509 asymmetric encryption in C #: http://www.csharpbydesign.com/2008/04/asymmetric-key-encryption-with.html

Answer 7

Agreed that you should avoid storing data if you can. But maybe you third party? If so, check out PCI standards . Look a little at the site and you will find the security measures that you need to implement.

Answer 8

Let's look at this requirement a little differently. Currently it looks like this:

As the owner of the product for website X, I want the system to temporarily store customer details so that I can restore the sale that was rejected by CC

Ppl tends to think like this and request functions this way. Now I think that your requirement is more convenient to describe as follows:

As a user, I want website X to be able to repeat the payment for my purchase, so I have no hassle to go through the verification process again, which is a real pain in ...

So, is there no explicit requirement to store anything (on your side)? Its only implied

Payment providers can provide software APIs for your trading account and the ability to attempt to reauthorize for a delayed attempt. I think @bashmohandes slipped away from this earlier

Not all payment providers can do this, but I think that it depends on their relationship with the banks involved. This is what you want to avoid, i.e. having a close relationship with banks.

Scenario 1: Assume Everything I Say Is True

You do not need to store anything except a link to an authorization attempt. Some payment providers even give you the sweet backoffice tool, so you don’t have to do your own to do re-authorizations. I think paygate does it

Your best bet, I think, is an interview with several payment providers. they should know this, like the backs of hands. This is potentially a null-code solution.

Scenario 2: Assuming I am completely wrong, but legally this is keeping CC files in order

So, you should temporarily store this data. I advise:

• use a two-way encryption method (of course) that is not vendor specific, so you can use any language / platform for encryption / decryption.
• separate the encryption / decryption service from your application and treat it as a black box
• use public / private keys for authentication for this service
• put this computer on a private network with your own firewall rules (it doesn't have to be a hardware firewall, but the hardware is better).
• your application servers will contact this machine via ssl (you can leave with a self-signed certificate, since it is located on your private LAN).

All that I suggested in scenario 2 is an obstacle, but in the end, perseverance wins the race to get to your data. The only way to absolutely protect the data is to disconnect your server from the air, but this option is a bit radical :-)

Scenario 1 will be enjoyable. Is not it?

Answer 9

View your t-magazines!

If you explain to your client the full impact (and the correction of requirements, if they are discovered due to compliance), then believe me, your "business requirements" will change very quickly.

If you have to save a credit card number (and I put forward the thought here that there is no reasonable scenario where you should), and you intend to use the built-in encryption for your database, think about it: what about your transaction logs?

If your transaction logs can display your credit card number in a clear form, then you are not observing and must pay a court audit of $ 10,000 to $ 50,000 on your site if you get caught. A budget for your own lawyer in case your client sues you because you should have known all this.

So, if you are going to store a credit card number, run the cipher in the code so that the transaction logs (insert or update) display the encrypted string, and not the card number in the box.

And you don’t even have a field or column in your database for CVV - encrypted or not - this forensic audit will show it (this will be the logs), and then your client will be a BIG, BIG problem. They will pay a fine and may lose their ability to accept credit cards. Your lawyer will be very happy.

Answer 10

I have a blog post that talks about this situation of storing sensitive data in a database. The blog post uses the String Encryptor class, which I built using the Triple DES algorithm, but you can plug it in if you want.

The blog post contains the video and source code that was used. You can check this out at http://www.wrightin.gs/2008/11/how-to-encryptdecrypt-sensitive-column-contents-in-nhibernateactive-record-video.html . I think this will definitely solve your problem.