Keeping Private Customer Data...Private?

Suffering Sekret Keys asks: "When I first started working for the company I'm with now, back in 1996, I was charged with finding a way to keep our customer credit card info secure in our database. Now that I'm smart enough to realize the flaws in this system, I am wondering how you avoid the catch-22 of needing to be able to encrypt/decrypt the data on the same machine that houses it, without exposing a secret key that could make that data more vulnerable in the event of an intrusion?" This question has been submitted a few times, recently, but this was the best one out of the lot. It seems many of you are wisely concerned about private data stored on your company's net, and the risks involved if it gets stolen. Well, now is your chance to discuss various solutions. How would you securely store your customer's private information, especially when it comes to critical pieces like credit card numbers?

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

Comments

I wonder...

[kill-hup]

I wonder if this question (and the others mentioned) have anything to do with this recent IDG story.

Why store secret key?

[demi]

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.

Re:Why store cc# at all?

[Sharkyfour]

The reason for this is so that our billing staff can handle the recurring billing.

It's right there in the article.

Old problem.

[AftanGustur]

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.

Data Integrity and Security

[buffy]

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

Building Secure Software

[Anonymous Coward]

This is what _Building Secure Software_ by Viega/McGraw is all about. It's a very good book and was reviewed recently on slashdot at http://books.slashdot.org/article.pl?sid=02/03/04/ 0354222

Here's an amazon link:
http://www.amazon.com/exec/obidos/ASIN/020172152X/ qid%3D1023135591/ref%3Dsr%5F11%5F0%5F1/103-9142405 -3353431

Re:avoid the problem

[reschly]

I've never used it myself, so I don't actually have an opinion, but here's what some other people think about paypal. Just incase you haven't heard other people's horror stories already.

Summerizing

[SirSlud]

Just a summy post to collect most of the points above that are good ideas:

- Use 'per record' encryption, where the records are encrypted each with a per-record unique key that is hidden from the outside (user-supplied is good, like a password, or if you need to decrypt without customer interaction, on a seperate box inaccessible from 'outside')

- You should have a method of 're-encrypting' records should a key(s) be compromised, to get the data safe as soon as possible after detecting comprimisation of your key(s).

- Dont ever decrypt - if you can get away with it, dont ever decrypt .. if you need the # for display on pages (like receipts), you only need to display the frist/last 4 digits for confirmation purposes, so only store those (encrypted). This is along the lines of minimizing the 'pot of gold' in a worst case scenario.

- Isolation .. depending on the data's sensitivity (and CC#s are supermega sensitive), you can opt for various levels of hardware isolation of the box that stores the key, via a serial cable or something.

- DONT ENCRYPT USING A KEY ON THE BOX ON WHICH THE DATA WILL BE STORED, or you might as well call your box a honeypot.

- make sure you use 'proofs' to verify the data, post encryption. Store the proofs on a box other than the data hosting box, so you can detect data comprimisation as soon as possible! (You could run a local data intergrity job nightly to detect mofified or currupted records.)

Everyone knows the worst can happen with computers - but if you did your best (and kept interested parties informed as to your efforts), then you wont/shouldn't be blamed if the worst happens. This is analagous to drunk driving ... everyone knows car crashes can happen, but being drunk during one is going to void any possible blame that could have been placed on people other than you.

Let someone else worry about it

[stuce]

TrustCommerce has a great system called BillingID's where you can submit all your credit card info for storage on our secure Linux servers. You are given a handle that you can use bill the customer at any time through our cool GPL'ed client API. Retrieval of the CC info is impossible so even if your server is compromised the hacker can't get your credit card information. This lets you bill customers at your leisure but lets you offload all the extra security responsibility onto us. Security is, after all, what we do. </shameless plug>

From my archives, a pretty good solution

[jukal]

You can find this also here:
Following Text authored by Albert Langer not me, posted to ZCommerce mailing list on Fri 09, Jun 2000 . Still very valid:

<clip>
Warning: Following ideas are "off the top of my head". Not verified.

Q. "Where do I store the decryption key so that the cracker who snarfs the database file can't get it (just in memory somewhere?), and yet have the system be able to boot itself, including having the key, without human intervention?"

A. "Using a 'one time' fast key in a client cookie".

Details:

1. Generate single Public/Private key pair off site. (Slow but only done once).
2. Store only the Public key on web server.
3A. Store Private key very securely on internal site with controlled and audited access etc.
3B. Or better still, immediately destroy it. Losing only the functionality marked * below.
(Above are common to several previous responses. Following are new.)
4. Compress each CC card as received to shorter equivalent bit string (eg convert the parts that are card type to enum, remove checksum, convert remaining ascii digits to large binary integer and concatenate with the enum. This makes the cookie below smaller, also removes some redundancy.
5. Use public key to generate and store encrypted copy of compressed CC number on web server. (Fast). Do NOT store or transmit to internal site, except on specific secure request with audit records maintained at web server as well as internal site. Use same precautions as would be used for storing plaintext CC numbers or private keys.
6. Generate XOR of encrypted copy and plaintext on server. (Very Fast).
7. Store the XOR in long term client cookie (expiry no later than CC expiry date, or add expiry).
8. Destroy plaintext of CC AND the XOR on webserver.
9. Steps 4, 5 and 6 MUST be carefully designed to leave no trace of plaintext or XOR on web server, eg in virtual memory paged to disk etc etc.
10. Step 7 MUST be designed so web server cannot store cookie in client unless transmission protected by secure transport (https).
11. Step 7 SHOULD be designed so client cannot transmit cookie to anybody other than the same server and with the same secure transport (possibly impossible and a key flaw).
<clip>

See the link provided above for benefits of this approach, this post is already too long :)

Not that difficult: break the problem down

[Jobe_br]

This problem (while common) is really not that difficult to solve, in your situation. Here's what you have:

1. e-comm server with 'Net access
2. need to store sensitive info
3. need to encrypt sensitive info

Break the problem down, especially the flow of information, sensitive and otherwise, because this is key:

• sensitive information flows from customers to your e-comm server via the 'Net
• sensitive information does NOT need to be seen by customers (e.g. CC#s, last 4 digits suffice)
• employees need access to sensitive information
• employees accessing data are 'trusted' (both in a personal sense and an access method sense, either an internal network or an encrypted VPN connection)

So, after sketching this down, here's what I've come up with:

1. You'll want three servers:
   • 'Net accessible web server, contained in a firewall's DMZ (demilitarized zone)
   • sensitive data DB server (restricted access from DMZ, unrestricted access from 'trusted' source)
   • 'trusted' web server (for employees)
2. sensitive information flows to DB server via well-defined interface, but not back (see above posts regarding serial cables, restricted ports, etc.)
3. auth info (success/failure) and de-sensitized information (last 4 digits, etc.) flows back to the 'Net accessible web server (to support e-comm apps)
4. Open communication to trusted server (secure to your hearts content, see posts on policy & social problems above, key point: trusted server should mean trusted server)
5. Employees access sensitive information via trusted server either from private internal net or VPN connections.
6. Make it impossible for anyone to access your sensitive DB server from the DMZ (this should be easy to). Once you've accomplished this, your information is secure, regardless of what you do on the actual DB server ... sure, you can still encrypt the data in your database (you should) and all that, a few different methods are described above, but in essence, by restricting the flow of information and then segregating the information repositories based on that flow, you've taken care of your problem.

This type of system allows for updating of information in the DB as well, if you want to allow this, you'll want to design some kind of authentication mechanism between the requestor of the update (the user's password would work) and the sensitive DB server. Otherwise, a cracker could, potentially, corrupt your sensitive data (not really a big deal since backups are being kept). If this is the worst that can happen, you're sittin' pretty.

Note: while this 'scheme' requires three servers, they don't necessarily need to be distinct (the one in the DMZ needs to be distinct, of course). The others, though - that's up to you, depends on your resources. Check out user-mode-linux if you want to logically distinguish servers on the same hardware. Encrypting the data files used for each user-mode-linux session should suffice to secure each session from the other, should the host become compromised (again, shouldn't be a consideration, this would only be done on a 'trusted' machine).

If anyone's more interested in what I've written down here, feel free to contact me via the contact info associated w/ my Slashdot acct.

Brice
--
WebProjkt
VP, Director of Internet Technology

S/N Ratio

[Kagato]

This is where S/N really comes out. It's obvious that many people on here haven't actually done e-com, or if so, not seriously. To clarify for others talking out the ass. The person needs to do recurring billing. You can't just get on VisaNet and say "bill that guy again". The card number needs to be stored. They also need all the billing address and phone number. This needs to be done for AVS. If you don't know what AVS is and you posted in the thread you're part of the noise. Not having all the info costs merchants real money. There's more to writing a good CC Number system than being able to patch a web form into Signio/Verisign.

Good ideas, seperate Database on a seperate machine. One way encryption systems. Big keys to limit brute force. You can do it in house all with Perl, or you can use several off the shelf packages that allow recurring billing via a reference number. However, few shrink wrap packages are Unix friendly. Most tend to be Windows (ugh) based.

If you were to do it yourself combine several forms of security. Place the DB on a seperate physical network. Dual nics in machines that need to talk to the DB. Give the machine an non-routed IP range. An extra firewall isn't a bad idea either.

Don't forget DB User Level security. Seperate logins for everyone. Limit what they can SELECT, UPDATE, INSERT, and DELETE. Most DB's have column level security. For instance you can give an employee rights to INSERT or UPDATE the cc number field, but not select it. If you can use SSL on the DB transport use it. Billing persons shouldn't need to see anything more than the last four digits of the CC num. That can be stored in a seperate field.

You might also want to consider seperating the CC Number DB from billing DB. Using a ref idea. Again, you can never be too secure.

You should also be looking at application security. A couple posts have talked about putting a serial link between the billing app and the credit clearing DB. It's not a bad idea, but it only takes a couple lines inserted into your perl code to start trouble. You should be looking at tripwire systems as well.

Just because you're paranoid doesn't mean they aren't out to get you.

Comment removed

[account_deleted]

Comment removed based on user account deletion