E-commerce Security

What steps are required when running an e-commerce site

[Jack_Hughes]

we currently run mals-e shopping cart software and manually process the credit card with a virtual terminal. we now require features that are not available from mals-e.

one solution is for us to run our own e-commerce site on our own server. given that this would require that we would have to store credit card details in our own database, what precautions are necessary in order for us to be 'safe'?

the thought that someone could break into our server and steal the credit card details there gives me real cause for concern.

[streetshirts]

I would suggest that you use a payment service provider, such as WorldPay. These are Bank accredited in terms of their security. This way you do not need to store any card details at all.

In fact, in the UK, many banks will not give you merchant numbers if you do not use one of their chosen payment providers.

[raywood]

martyt gave me some good advice here.

[webmasterworld.com...]

Understandably he didn't want to get too detailed in a public forum, but you should read the posts in that thread.

[Jack_Hughes]

thanks raywood. your're right that is good info. i don't think i have too big a problem with the hosting company. they are big enough to have a reputation to protect.

i think the point of deleting the cc info as soon as it has been used is a very valid one.

[raywood]

I don't think you should rely on your hosting company to protect your data. There are many possible security holes that might be in your own code or config files or permission settings. The host should protect the server as well as they can, but it's not their responsibility to tighten up your code. You probably have a database username and password in there somewhere. How well have you protected it?

What works for me is a combination of luck and paranoia.

[Jack_Hughes]

No it certainly isn't our hosting companies responsibility. we are planning on using an off-the-shelf e-commerce system, maybe commercial, maybe open source. we have quite decided yet (we are still working on the requirements). We would expect the e-commerce system to encrypt the cc info and place it into the db for us. also, it should protect info like db user name & passwords too. not much of an e-commerce system if it doesn't protect the integrity of the info it contains.

[Web_Doctor]

I haven't read the other post yet, but there is a piece of information that needs mentioning. The three-digit codes on the backs of credit cards (CVV2 and CCV codes) are by credit card company regulations not to be stored. That means they should not be stored in any location that can be compromised.

Obviously if your a mom & pop shop you should be able to trust your spouse with the information. However, it should not be stored on any server regardless of the hosting company security policy.

I haven't covered all bases yet, but I am investigating the situation represented in this article. [ecommerce.internet.com...] I would recommend reading it.

[jamesa]

>> expect the e-commerce system to encrypt the cc info and place it into the db for us

Problem is that the password to encrypt/decrypt the data would need to be stored in the scripts. If someone could get to your database, they probably can get to your scripts as well. Web servers are not secure by their very nature.

Easiest/cheapest solution. Use a cc processor like mentioned in this thread (I like AuthorizeNet) so you don't need to store the data.

If you need to store it in a database, set up a separate database server that's firewalled and closed shut as can be. Don't make it accessable to the public, only on a private LAN behind your webserver. Have the shop cart POST to the db server and let the db server handle the encryption. Don't allow the db server to pass cc data back to the web server. If you need to do a recurring charge, send the db server an ID and let the db server process the transaction. No need to pass CC data.

With this setup, the only way to get to the db server is through the web server. So someone would need to compromise the web server first, before trying to hack the db server. Since the db server does less it could be tighter (securiity). Hopefully you'd detect an intrusion on the web server before anyone had a chance to bust into the db server.

I wrote this real quick, hope it makes sense ;)