9

I've been tasked with handling some credit card data storage. After reading the PCI compliance questionnaire ( including the NIST 800-57) and some googling ive found few resources that are both (kinda) recent and compliant.

Here are some resources ive found:

http://www.dijksterhuis.org/creating-salted-hash-values-in-c/

http://msdn.microsoft.com/en-us/magazine/cc164054.aspx

Is there a best .NET algorithm for credit card encryption?

My Question: The basic coding logic for encrypting and decrypting the information seems to boil down to the way Yossi does it here:

http://yossi-yakubov.blogspot.com/2010/07/aes-encryption-using-c-short-way.html

Am i correct ? Any more 'standards compliant' methods ? Any other resources someone can recommend?

Thanks alot

UPDATE I dont need to transmit the credit card numbers - i need to recieve and encrypt them for storage in the DB. If this data ever gets transmited it is always done over HTTPS ( so im good in that respect right ? )

Yes i missed this important information when i first posted - but thanks alot for the quick replys, really.

Community
  • 1
  • 1
JanivZ
  • 2,265
  • 3
  • 25
  • 31
  • 1
    http://www.bouncycastle.org/csharp/; http://stackoverflow.com/questions/120116/encryption-libraries – sehe Aug 09 '11 at 13:35
  • wow, first off thanks for the quick reply. I've only started learing this subject - however it seems that RSA encryption requires public/private key senarios wich is not a part of my requirements - thats why i headed for the AES algos. Am i not getting this ? :P – JanivZ Aug 09 '11 at 14:17
  • @user606724: Depending on the length of data, you'd either use RSA only (if the data is very small) or RSA + AES. Using AES alone requires you to somehow transmit the secret key to the other side for decryption, since the same key is used for encryption and decryption. A simplified view of HTTPS is the browser verifies the server with its certificate, generates an AES encryption key with the public RSA key, submits that to the server who decrypts it with their private RSA key. Once the key is transmitted, the actual data in the session is encrypted with AES, since AES doesn't have length limit – Joshua Aug 09 '11 at 14:29
  • Ive updaed my question - i am not transmiting this data ( or not supposed to any way) - thanks again for the quick replys guys – JanivZ Aug 09 '11 at 14:36

2 Answers2

6

It sounds scary that someone outside of a certified credit card institute tries to save this information, no matter if encrypted or unencrypted (I assume that it's not one-way encrypted).

Does your business case really require that? Does your company really want to take the risk of storing credit card numbers?

thoean
  • 1,106
  • 8
  • 15
  • 4
    +1: The most important thing to know about storing credit card numbers is **don't**. Hand off that responsibility to a provider who specializes in it. There are all sorts of requirements such as physical security that go way beyond just the code you write. – Greg Beech Aug 09 '11 at 20:06
  • 1
    When you store credit card data you provide an incentive to hackers to break in to your system. Plus, you're an amateur at protecting this data. If you have USAEpay or Authorize.net or someone else handle this for you, you might still be responsible but you get the benefit of all their expertise. – DavidJBerman Aug 09 '11 at 21:35
  • Yah, it is scary. Thats why i turned to you guys for some advice. My only foucus is on the code side of the security - hardware and its security will definetly have to also be up to industry standards. Unfortunatly our buisness does require that we store the numbers - but i wasnt aware of the services you mentioned - will definetly look into them. Thank you very very much for your advice guys. I will mark this as answered tommorow if i get no more input :P thanks again – JanivZ Aug 11 '11 at 08:10
  • Make sure you understand your **legal** requirements if you store credit card data. https://www.pcicomplianceguide.org/pci-faqs-2/#2 – Bradley Uffner May 22 '15 at 13:42
0

I see a lot of answers related to "you shouldn't store credit cards". Remember, a lot of monthly subscription business' require this. You have to develop your own software to do it, or use 3rd party software that does it.

Another example is a retail location having a customer base where the clients setup for monthly auto-withdrawal. This is common in different types of business' where monthly costs occur. E.g., dance lessons for kids.

Lance
  • 1