Forum Moderators: buckworks

Message Too Old, No Replies

Storing Credit Card Numbers

How much security is enough?

         

spikey

9:35 pm on Oct 9, 2003 (gmt 0)

10+ Year Member



There was a post about the paranoia of storing credit card information awhile ago. [webmasterworld.com...]

A credit card number is a scary piece of information but neccessary when you run an ecommerce site.

The logical thing to do is to encrypt the numbers in the db. But is that enough? Where do you store the key? If you're (rightly) taking precautions that an intruder might get access to your database you certainly don't want your encryption key in there. Is storing it in the code any better?

It seems to me that the next step would be to have your key manually input into your server's global memory when it's started. But then you either need to have a lot of people know what that key is or you need a few poor people who are going to have to be on call whenever it's rebooted.

Anyways, I'd love to hear opinions on how much is enough and how much is just inconvenient.

sarciszewski

5:57 am on Oct 10, 2003 (gmt 0)

10+ Year Member



You bring up an interesting point. I've built several succesful e-commerce websites for various clients and I am currently building a new one that is actually my own business.

In every case, I have strongly recommended NOT storing credit cards, period! I believe it is a complete fallacy that credit card numbers need to be stored by an e-commerce retailer in probably 99% of cases.

First of all, if you sell goods or services that are a one-time purchase (not recurring fees that you charge customers) - then what possible purpose would you have for storing customers' credit card numbers? Now before you argue that storing credit card numbers is convenient for customers because they don't have to re-enter these numbers on subsequent shopping visits, let me tell you that I completely disagree with this. I believe that it is a much smarter move to simply not offer this as a feature, and tout the security of the system, i.e. you don't store credit cards, and therefore there is NO chance of them being stolen. I believe that having this as a security feature is far more superior of a selling point for a customer to make a purchase with your website rather than feel great about not having to re-enter their credit card number.... (are people really that lazy?!) ....

Regardless, if you are processing orders in real-time you should have no need to store these credit card numbers, that is the job of your transaction processor, and if they get broken into, the onus is on them, not you.

If you DO NOT do real-time transactions, instead you capture credit card numbers and then process the transactions manually, you should flush the credit card number that is stored RIGHT AFTER you have processed the order, so that there isn't this giant database of numbers that continues to pile up.

Let's face it, the number of Internet attacks is on the rise. They are becoming more sophisticated, and in my opinion it's just silly to store such a tempting database of information, just waiting to be hacked.

TallTroll

11:13 am on Oct 10, 2003 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



If repeat custom is something you need / want, then I would offer your regular customers the chance to register with you, and get a credit account, typically by setting them up as a customer record in your accounts software. This means you can store any sensitive details on a non-web machine, thus offering great security, and still offer that convenience factor.

There is also the benefit of shifting some (not all) the onus of security onto the customer. Once you have sent them account details, they have some responsibility for keeping that information secure. The most any security failure on your server could release would then be account details for your own site only