Section 6.5 One-Way Credit Card Data Path for Top Security | Real World Linux Security Prentice Hall Ptr Open Source Technology Series

6.5 One-Way Credit Card Data Path for Top Security

For many e-commerce sites, the most confidential information that a customer can tell the site is the customer's credit card number and expiry date. Several e-commerce sites (including some large ones) each have had thousands (sometimes many tens or even hundreds of thousands) of their customers' credit card data stolen by crackers and then have had to respond to extortion demands. A number of crackers have made good on their threats and put quite literally thousands of these stolen credit card numbers on cracker sites where they were used illegally to obtain goods and services. Most e-commerce sites keep the database of customer information on the same system as the Web server and CGI programs. This is begging for trouble. Simply putting the database on a separate system is not enough because if the CGI programs can attach to the database across the e-commerce site's LAN and send database requests to get credit card data, security has not been improved.

I have come up with the concept of a one-way credit card data path. By this, I mean that the credit card data flows only one way and that way is into the credit card server (database) system but data never flows out of the credit card server (except over a separate hardware path to the bank or service that is processing charge requests and only to process individual transactions). The credit card database system would be a Linux system (or possibly a UNIX system) dedicated to this one application. It would have no other applications on it because each application would be a potential security hole. It would be hardened for the highest security. This technique works equally well for other types of data. Also see "Trust No One The Highest Security" on page 356.

Tip to consumers:

Use only one of your credit cards for all of your online shopping. Thus, if there are fraudulent charges on any of your other cards, you will know that online shopping was not involved. Do not use debit cards for online shopping because you do not have the same legal protection as when using credit cards when disputing charges in the U.S. Terminate your browser before leaving your desk to prevent someone else from seeing windows containing your credit card or account numbers. SSL does not inhibit the Back and Forward buttons.

It would have a separate (private) LAN to the Web server and the Web server would have a separate dedicated network interface card (NIC) to this private LAN to prevent sniffing. Consider encasing the LAN in steel pipe, possibly with segments spot-welded together. An alternative to a private LAN would be encryption using SSH or a VPN. These are discussed in "Protecting User Sessions with SSH" on page 409 and "VPN Using FreeS/WAN IPSec" on page 428. Certainly, it would be in a high-security area, preferably an area separate from other systems. Note that the separate systems for separate functions is part of the philosophy already discussed in "United We Fall, Divided We Stand" on page 115.

There would be no request implemented that would allow another system to query for a complete credit card number under any circumstance (with a single exception discussed later). Thus, neither a cracker cracking your Web server nor even a rogue employee (except for the few trusted with it) could get the credit card data from it. So long as there are no buffer overflow vulnerabilities (which is discussed), this system should be very secure. There are no other services to crack, preferably not even SSH. There are no passwords to crack. Spoofing will not work because this system does not trust any system at all.

When a customer establishes an account and specifies a credit card, the CGI sends the following message to the credit card server:

 ADD user name account number credit card type, number, expiry date

When the customer wants to make a purchase, the following message is sent to the credit card server:

 CHARGE user name account number amount

The credit card server then would contact the credit card processing bank (through a private network) to charge the amount, store the authorization number if successful, and then return either "success" or an appropriate error message such as:

 would exceed credit limit

 card stolen by the cult your college kid joined

Note that this communications link to the bank that processes the credit card would be on completely separate hardware from the rest of the network so that if a cracker broke into, say, the Web server, he could not sniff the network for these authorization requests because they would not be on that network (even though this would be much less of a problem than the entire database being at risk). This is illustrated in Figure 6.1.

Figure 6.1. One-Way Credit Card Data Path.

graphics/06fig01.gif

If the user has multiple credit cards on file and you want to present him with a list of them, the following request might be used:

 LIST CARDS user name account number

However, in the card data listed the credit card server would show only the last three digits; the rest would be replaced with X characters. Thus, the LIST CARDS command would show

 XXXX XXXX XXXX X314 XXXX XXXX XXXX X159 XXXX XXXX XXXX X265

If a user wanted to remove a credit card from his file, say, because he no longer has it, he could click the desired one output by the LIST CARDS and the following request would be sent:

 REMOVE CARD user name account number XXXX XXXX XXXX X314

The credit card server would match this against the actual number and flag that record as removed.

As you can see, there is no request to get the full credit card number out of the credit card server; thus, this security would be very hard to break even if a cracker was able to make himself root on the Web server or sniff on the company's LAN.

Obviously, the credit card server system would have the very tightest security with no services at all except this custom credit card request service and possibly SSH. The server code that receives these commands should be written very carefully (and the code audited very carefully) to avoid buffer vulnerabilities. Libsafe should be used on it, too, to detect any buffer overflow problems; it is explained in "Stopping Buffer Overflows with Libsafe" on page 331. For even more security, encrypt the confidential portions of each record with a suitable key, such as the person's last name and postal code. Using one key for the entire database is almost worthless as it would be used constantly.

For those rare occasions where your people would need to see the full credit card number (such as in case of errors with the bank or responding to a customer complaint), your credit card specialists would need to log in to the credit card server's console. You should pick hard-to-crack passwords rather than risk your credit card specialists picking poor passwords. Not even your regular customer service people would have access to this system.

A possible alternative for large shops would be to use SSH to connect to a program on the credit card server from another secure Linux box that is dedicated to this task (of dealing with bank errors and customer complaints needing the full credit card number) and which maintains the same security and, of course, offers no services except an SSH client. I will call this second box type (of which there could be more than one) a credit card specialist's system.

Neither the credit card server nor the credit card specialist's system should have any browser (because they are not to be trusted) or other unnecessary software. See "Hardening for Very High Security" on page 306 for some ideas on how to harden these systems. They should have IP Chains running to block all traffic except SSH and, for the credit card server, the credit card service port number. (You will pick this port number.) Although not a SysAdmin matter, these specialists would need to be trained carefully to never give out the credit card numbers to anyone except bank personnel and only if they made the phone call to the bank (and not if the "bank" called them).

Obviously, your Web server should not retain any copies of the credit card numbers that it handles. You should protect against sniffing by having a separate network card in the Web server for a private LAN that only connects it to the credit card server, and SysAdmins should not run sniffers on this device because a cracker may find their sniffer output files containing credit card numbers. Use of encryption during transmission to the credit card server is suggested. Clearly, the credit card numbers will reside briefly on the Web server but that is a much smaller problem, because the cracker can get only the credit card numbers of people that become new customers (or add card numbers) during the time before the cracker is detected and expunged. A clever thief can obtain some of your customers' credit card numbers via the common scam discussed in "The Trail of Compromised Data" on page 704. It is hard to guard against this.

Top