Slashdot Mirror
Keeping Private Customer Data...Private?
"I chose 1024-bit PGP encryption with a long passphrase. I use the Cryptix java package to handle the encryption from a Perl script (the reasons for this are legacy related, but I'm in the position where I can start clean if need be -- a Perl-only solution would be great).
The thing that makes me nervous is the secret key being stored on the machine that houses the database. The reason for this is so that our billing staff can handle the recurring billing. (They have a web interface where they must enter the passphrase to gain access to the credit card information.)
I have realized for a long time now that if someone gained full access to this machine, they could fairly easily run a brute-force attack on the encrypted data, if they found our secret key on that machine. But when we recently worked on our privacy policy, this potential problem became more important.
What changes could we make to our setup so that we can encrypt/decrypt the credit card information on the same machine that houses the data, while making it as hard as possible to decrypt the credit card data assuming the entire machine was stolen (or cracked)?
We are a very small company. How do "the big boys" handle these things? What is the best book on this particular subject?"
While this setup may work well for credit card numbers, what about setups that will protect other personal information like a customer's address and phone number? Would such information be practical to obfuscate in such a manner?
I've done something similar before (though it was passwords, not credit card data) and the trick is to not store the secret key anywhere, especially on the server that stores the data.
I coded a server component that could decide whether a requester could view an encrypted datum (for example, if the requester authenticated correctly) and decrypt it using a key stored only in memory, that had to be entered by a human being to start the server. The humans who could administer the server memorized the key. A small enough amount of data was stored that changing the key was feasible.
This server was in perl, but the encryption/decryption code was in C; I used blowfish (libblowfish) and also stored the key in a C buffer pointed to by a perl scalar, and used the mlock() system call to prevent the key from being swapped--an alternative might be to use OpenBSD where it is possible to encrypt the swap area.
Anyway, I hope that gives you some ideas. Any form of storing or recording the decryption key reduces to storing the credit card numbers in plaintext, so you should avoid that.
demi
A commonly used solution in high-security environment is to isolate the database machine from the network. I.e no network card. You then connect the database machine to the data processing machine via either a serial cable, parallel cable or similer that doesn't have a network stack on top of the driver.
You then have to create a client/server/queue manager on both ends.
Your security problem is now reduced to the functionality of the client/server that talks over the cable and performs requests on the database.
(Assuming of course that you can control access to the console)
A bit of effort, but it works.
echo '[q]sa[ln0=aln80~Psnlbx]16isb572CCB9AE9DB03273snlbxq' |dc
As with most security related topics, depth layered solutions are best. Of course, design your network and connectivity with least access in mind--i.e. the database server itself is never directly accessible via the Internet, or even your first layer of permimeter defense. Typically, only http and https are externally acessible, with perhaps a few others like DNS, and FTP.
Usually your database will either be accessed by your web servers directly, or through an application server. Limit access to your database explicity to these addresses, through both the database configuration, and, if possible, IP-level configuration (like iptables in Linux). For each client connecting to the database (be them web servers or application servers) have then use unique password keys (and users, too, for that matter.)
Finally down at the application layer (we've done network, and server layers so far) you need to be more careful than ever. First, do the obvious, don't store sensitive material (read: credit cards) in plain text ANYWHERE. At list build in some kind of cipher key (crypt, if nothing else) that will encode the data in the database. If possible, you may want to look at more elaborate schemes for storing data in such a fashion. Beware, this is the piece of the puzzle that many will spend a lot of time focusing on, which is good, but not the whole shebang. Also note, any fields that you store encrypted, you will not be able to use easily as an index field.
Another oft forgotten place to focus on, is in the tools that you use for manipulating and storing the data. Everything above is worthless, if you have a careless programmer who writes a utilitiy that doesn't sanatize user input prior to executing an SQL query. A tremendous amount of the hacks you see out there are due to tools like these that are very vulnerable to misuse--since they were designed to have the ability to access your data, your security measures are for naught.
Make sure your programmers understand how the data is being stored both in the database, and the computer (ie. buffers, sanatized user input fields, etc...)
These are by no way complete, just thoughts of things I've had to deal with in the past while facing similar issues. Hope they help.
-buffy
Comment removed based on user account deletion