The members of ECTalk Recently on the EC Talk discussion list, a reader posed a query regarding what precautions should be taken when storing credit card information on a server :
SO asked:
"When you have a database residing on a server that is storing credit card details, what security precautions do you take? Online processing of the credit cards costs too much for [my] client in this case."
SD offered a simple solution:
"An often used solution is to store the half of the credit card number in the database and send the other half by mail to the shop manager."
DA provided several guidelines for encryption procedures:
Several ways to approach this depending on who administers the db server:
- Secure the area which contains the database server
- Secure admin access to the database server to a few trusted individuals
- Encrypt sensitive data fields in the database
- Do not store the encryption key in a program or in a file on the same site as the server (or write it on the wall next to the server)
- Access the encrypted data thru SSL and require that the encryption key be provided by the person accessing the data.
- After 2-3 failed attempts to enter an incorrect key, disable access to the program.
"Some, or all of these techniques will relegate the database and application programs to being "vehicles" to store encrypted data, and securely transmit decrypted data."
"The database knows the encrypted data but not the key or the algorithm and is not accessible to long duration hacking efforts."
"The program knows the algorithm, the encrypted data, the key, and the decrypted data, but only for the duration of the secure transmission."
"Only an approved individual can provide a valid key and cause all the other components to operate."
WE offered this advice:
"Given the brief description of the client''s situation, one solution is to simply outsource the credit card processing (to any one of a huge number of companies such as Paycom, iBill, and others). Such a processor may well have more payment method options than you could readily set up yourself, and definitely much more effective "scrubbing" of credit card charges. Many of these processors have huge "negative" databases of credit card holders, and "positive" screening and scoring methods/systems--in addition to the screening services you would receive from Visa, for example. You won''t need to worry much about the security of the transaction if you get a good processor to handle the transactions, which are routed to the processor''s site. The processor handles all the security, encryption, chargebacks, etc. Typically 24/7 reporting on all transactions is available, and some of the processors have very sophisticated and informative interfaces."
"Many of the processors can even predict, given the nature of your business and your client base, what your charge declination and chargeback ratios are likely to be. Obviously you pay for such services, but you avoid having to deal with a host of problems--or only have to be marginally involved with certain problems. My recommendation of a guiding principle: look at the truly "net" cost, not only of dollars, but of margins of safety, your effort and time involved, collection costs and likely success, and any other relevant factors."
SO replied with:
"All this stuff sounds like it would cost a fair bit of money. The client in this case is self-employed and works from home, so he won''t be spending a lot of money on this. He can process credit cards off line, so he just wants to enable people to be able to send him their credit card details along with a simple order form from his Web site."
"Ideally the content of the order form would just get encrypted and emailed to him, but I don''t really see a cheap solution that does this without using SSL first, for example, to encrypt the details sent from the Web site, before using a Web application, along with something like PGP, to generate an email."
"The cheapest solution is not to bother with the cost and installation hassles of PGP, and just set up SSL on the site, store the details in a database, and allow him to access the database to get the order details. I would inform him of an order by generating a non-secure email with order details, but excluding the credit card details."
"My question is, how do I make sure that the database sitting on the server with all this information is secure? Should the data, which includes credit card details, be encrypted, or is it enough to put the database in a directory that is not accessible over the web? Should the database just be password protected?"
SK offered this advice on the secure server question:
"Another solution is to have the credit card information never leave the secure server, and have a notification e-mail sent that credit card information has been left. Then the client can enter the password-protected secure server and process."
TL discussed the dangers of storing credit card data on a Web-accessible server:
"I''d like to add that if you''re determined to keep credit card details on your own server, then you must at least store them as encrypted, as others noted (including DA''s excellent guidelines for encryption procedures on-site - see above). It is not "enough to put the database in a directory that is not accessible over the Web," since this information will somehow be Web-accessible (either in the delivery of the credit card details to the database or, as you noted in another section of your post, providing your client the ability to "access the database to get the order details." That means this database will be connected to the Web in one way or another, even if it''s behind a firewall. The best way to protect such a database is to make sure it sits on a separate box from your Web server, encrypt the contents AND, in effect, make ODBC database traffic the only traffic ''qualified'' to access the server (in addition to the password-protection/software key of encryption). This may not be your cheapest option, although it might be cheaper than facing class action lawsuits if your credit card information gets hacked."
"Otherwise it might be a good idea to more seriously consider WE''s ideas on outsourcing the credit card processing to someone who''s got all the systems in place to handle it. I''d recommend doing a little more research on comparing the prices of implementing an encrypted database on a separate server and making sure your firewall was properly configured to the costs of outsourcing credit-card handling, which are generally spread out over time and may be more cost-effective in the long run. In this case, a quick, cheap, and easy DIY approach has definite downside liabilities you should definitely consider."
PC add a few thoughts on credit card storage on a server:
You can reduce your exposure by only holding the credit card numbers during the fulfillment step in the process. In other words, when the order is completed, delete the credit card number. Of course, this doesn''t allow you to store credit card information for your user''s future orders, but it does reduce the risk.
DA brought up a few points about the dangers of NOT storing credit card information:
There are several problems with *not* retaining credit card info beyond fulfillment:
What if the item is out of stock and the order can''t be fulfilled?
What if there is a return/cancellation and you must issue a void or credit?
What if the charge is contested by the holder or provider?
How do you provide an audit trail?
For more information on choosing a payment provider, check out Ecommerce Guide''s Payment Solutions Reviews.
IE 7
Firefox 2.0
