[ACCEPTED]-Storing credit card details-pci-dss

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

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

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

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

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

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

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

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

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

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

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

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

Taken from this answer:

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

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

At the 10 end of the example the SecureString is converted 9 into a regular managed string, which makes 8 it vulnerable again (be sure to use the 7 try-catch-finally pattern to Zero the string 6 after you're done with it). SecureString's 5 use is in reducing the surface-area of attack 4 by limiting the number of copies the Garbage 3 Collector will make of the value, and reducing 2 the likelihood of being written to the swap 1 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);
}

Agreed that you should avoid storing the 4 data if you can. But maybe you are that third 3 party? If so, get familiar with PCI standards. Look around 2 a bit on the site and you'll find the security 1 measures you are required to implement.

It costs somewhere in the neighborhood of 40 $30,000 to become properly compliant and 39 to be able to do that kind of stuff. You 38 are better off using a 3rd party payment 37 service. Personally, I recommend Element 36 Express, and they have a "Hosted" solution 35 that bypasses the PCI-DSS PAPDB compliance. I've 34 had to convert to this for my own applications, even 33 a Point of Sale machine!!! It's a big pain, but 32 we're a small company.

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

The above link has 31 some good information about the costs associated 30 with becoming compliant. We have had customers 29 ask us to store credit card numbers, and 28 we won't do it because we could be fined 27 as well. Not good. Don't open yourself 26 up to liability.

Edit:

Additionally, if you 25 DO decide to store the credit card information 24 you definitely need to consider the forms 23 of encryption you are going to use. Symmetric 22 ? Asymmetric ?

If you do Symmetric encryption 21 (Passkey) then you open yourself up to some 20 serious security vulnerabilities if the 19 server(site) that has the key (needed to 18 encrypt) is compromised in any way. Remember, even 17 compiled code won't hide a text key.

If you 16 use Asymmetric encryption (public/private 15 keypairs) then you run into some additional 14 issues, but if the primary public facing 13 server is compromised they will only have 12 the public key, and if they also access your database.. they 11 won't be able to decrpyt the contents.

The 10 question then is, where do you store the 9 private key ? Do you have someone paste 8 it in from their local computers when running 7 admin functions.. have a separate application 6 that runs on the desktop to view orders, etc.

There 5 are a lot of things to take into consideration.

Final 4 note: Use a payment gateway (Element Express, Authorize.NET, Paypal, etc.) and 3 don't store any credit card info locally. :P

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

Lets look at the requirement a little differently. Currently 42 it looks like this:

As a product owner for 41 website X i want the system to temporarily 40 store a customers cc details so that i can 39 recover a sale that was declined by the 38 CC company

Ppl tend to think like that and 37 request features in that manner. Now i think 36 your requirement is more conveniently described 35 as follows:

As a user i want website X to 34 be able to retry payment for my purchase 33 so i dont have the hassle of having to go 32 thru the checkout process again coz that 31 is a real pain in the...

So there's no explicit 30 requirement for storing anything (on your 29 side) is there? Its only implied

Payment 28 providers can provide programmatic APIs 27 to your merchant account and the ability 26 to attempt a re-auth on a declined attempt. i 25 think @bashmohandes eluded to this earlier

Not 24 all payment providers can do this however 23 i think its dependent on their relationships 22 with the banks involved. Thats the stuff 21 you want to avoid ie. having a close relationship 20 with banks.

Scenario 1: Assuming all i said 19 is true

You don't have to store anything 18 but a reference to the authorization attempt. Some 17 payment providers even give you a sweet 16 backoffice tool so you dont have to make 15 your own to do re-auths. I think paygate 14 does this

Your best bet i believe is to interview 13 a number of payment providers. they should 12 know this stuff like the back of their hands. This 11 is potentially a zero-code solution

Scenario 10 2: Assuming i'm like totally wrong but legally 9 this storing CC stuff is ok

So you have to 8 store that data somewhere temporarily. I 7 advise:

• use a 2-way encryption method (naturally) that is non-vendor specific so you can use any language/platform to encrypt/decrypt
• decouple the encrypt/decrypt service from your app and treat it like a black box
• use public/private keys for authentication to this service
• put this machine on a private network with its own elevated firewall rules (doesn't have to be a hardware firewall but hardware is better)
• have your app servers communicate with this machine via ssl (you could get away with a self-signed cert since its on your private LAN)

All i've suggested in scenario 2 6 is hurdles but eventually persistence wins 5 the race to get to your data. The only way 4 to absolutely secure data is to unplug your 3 server from the ether but that option is 2 a little radical :-)

Scenario 1 would be 1 nice. Wouldn't it?

Consider your t logs!

If you explain to your customer the full 28 impact (and remedial requirements if they 27 are found out of compliance) then trust 26 me, your 'business requirements' will change 25 very quickly.

If you must store the credit 24 card number (and I advance the thought here 23 that there is no reasonable scenario where 22 you should) and you intend to use a native 21 encryption built-in to your database, then 20 consider this: what about your transaction 19 logs?

If your transaction logs could reflect 18 a credit card number in the clear, then 17 you are out of compliance and should budget 16 for a $10,000 to $50,000 forensic audit 15 at your site if you get caught. Budget 14 for your own attorney in case your customer 13 sues you because you should have known all 12 this stuff.

So if you are going to store 11 a credit card number, run the cipher in 10 code so the transaction logs (insert or 9 update) reflect a ciphered string, not the 8 card number in the clear.

And don't even 7 have a field or column in your database 6 for CVV - encrypted or not - that forensic 5 audit will reveal this (so will the logs) and 4 then your customer is in BIG, BIG trouble. They 3 will pay a fine and could lose their ability to accept 2 credit cards. Your attorney will be very 1 happy.

I have a blog post that deals with this 8 exact situation of storing sensitive data 7 in the database. The blog post uses a String 6 Encryptor class that I built using a Triple 5 DES algorithm but you can plug in your own 4 if you would like.

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