Data Encryption

Question

Hi

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 whereby we setup a mechanism to encrypt and decrypt but of ourselves cannot decrypt any given number.

What I am after is a way to secure this information even down at the database level so no one can go in and produce a file of card numbers. How have others overcome this issue? What is the 'Standard' approach to this?

As for usage of the data well the links are all private and secure and no transmission of the card number is performed except when a record is created and that is encrypted so I am not worried about the front end just the back end.

Answer 1

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 2

Well the database is ORACLE so I have PL/SQL and Java to play with.

Answer 3

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 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

I'd symmetrically encrypt (AES) a secure salted hash (SHA-256 + salt). The salted hash would be enough with a big salt, but the encryption adds a bit extra in case the database and not the code leaks and there are rainbow tables for salted hashes by then or some other means. Store the key in the code, not in the database, of course.

It's worth noting that nothing protects you from crooked teammates, they can also store a copy of the date before hashing, for instance. You have to take good care of the code repository and do frequent code revisions for all code in the credit card handling path. Also try to minimize the time from receiving the data and having it crypted/hashed, manually ensuring the variable where it was stored is cleared from memory.

Answer 6

This is what we do: How Is Your Sensitive Data Encrypted In The Database? That way even if you steal our web + database servers you can't decrypt it

Answer 7

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 8

Unless you are a payment processor you don't really need to store any kind of CC information.

Review your requirements, there really is not many cases where you need to store CC information

Answer 9

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 10

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.

Answer 11

I would try and explain, but this article does a pretty good job.

http://www.di-mgt.com.au/cryptoCreditcard.html