Data Encryption

Question

A database that stores a lot of credit card information is an inevitable part of the system we have just completed. What I want though is ultimate security of the card numbers w

Answer 1

Don't store the credit card numbers, store a hash instead. When you need to verify if a new number matches a stored number, take a hash of the new number and compare it to the stored hash. If they match, the number is (in theory) the same.

Alternatively, you could encrypt the data by getting the user who enters the card number to enter a pass phrase; you'd use this as an encryption/decryption key.

However, anyone with access to your database and sourcecode (ie. you and your team) will find it trivial to decrypt that data (ie. modify the live code so that it emails any decryption keys entered to a disposable Hotmail account, etc).

Answer 2

There's no shortage of processors willing to store your CC info and exchange it for a token with which you can bill against the stored number. That gets you out of PCI compliance, but still allows on demand billing. Depending on why you need to store the CC, that may be a better alternative.

Most companies refer to this as something like "Customer Profile Management", and are actually pretty reasonable on fees.

A few providers I know of (in no particular order):

• Authorize.NET Customer Information Manager
• TrustCommerce Citadel
• BrainTree

Answer 3

If you are storing the credit card information because you don't want the user to have to re-enter it then hashing of any form isn't going to help.

When do you need to act on the credit card number?

You could store the credit card numbers in a more secure database, and in the main db just store enough information to show to the user, and a reference to the card. The backend system can be much more locked down and use the actual credit card info just for order processing. You could encrypt these numbers by some master password if you like, but the password would have to be known by the code that needs to get the numbers.

Yes, you have only moved the problem around somewhat, but a lot of security is more about reducing the attack footprint rather than eliminating it. If you want to eliminate it then don't store the credit card number anywhere!

Answer 4

If you're using Oracle you might be interested in Transparent Data Encryption. Only available with an Enterprise license though.

Oracle also has utilities for encryption - decryption, for example the DBMS_OBFUSCATION_TOOLKIT.

As for "Standards", the proper standard you are interested in is the PCI DSS standard which describes which measures need to be taken to protect sensitive credit card information.

Answer 5

It would be helpful to know the DB server and language/platform types so we could get more specific, but I would be looking into SHA.

Answer 6

For an e-commerce type use case (think Amazon 1-Click), you could encrypt the CC (or key) with the user's existing strong password. Assuming you only store a hash of the password, only the user (or a rainbow table - but, it'd have to be run on each user, and would not work if it didn't come up with the same password - not just 1 that hashed the same) can decrypt it.

You'd have to take some care to re-encrypt the data when a password changes, and the data would be worthless (and need to be reentered by the user) if they forgot their password - but, if the payments are user-initiated, then it'd work nicely.