SSL Reselling and an E-Commerce Site

[clivejo]

I was just wondering if anyone has an e-commerce site running on RSP.

I have a few questions regarding it.

1) Is it secure to take credit card details via an SSL connection but on a shared server?

2) The SSL resellers offer a RapidSSL cert, which needs a dedicated IP address and offers a $10,000 USD warrant. What are the terms of this warranty? Does the warranty cover shared servers?

Any tips or advice greatly appreciated!

[bertwhite1]

The amount of security depends on the certificate, not on whether you have shared, vps, or dedicated hosting. The $10,000 warranty covers the end user if RapidSSL mis-issues a certificate.

[clivejo]

So the warranty is not to cover end user costs if sensitive information falls into the wrong hands? (ie credit card number being stolen)

My reason for asking is that I would have thought a shared server would be more vulnerable to attack. Maybe even via another user sharing the same server?

[bertwhite1]

If they were to mis-issue a certificate to a fraudulent site, that fraudulent site has an SSL link with an end user and as a result of this the end user loses money when the end user had what they thought was a "trusted session". This is what the warranty is for. As far as shared hosting vs. other types, I believe the general consensus is yes, shared hosting is more easily "hacked" but I'm sure there are people that know how to compromise VPS and dedicated servers as well.

[clivejo]

Do you know anyone who takes credit card payments and processes them via a gateway, being hosted with RSP? Id like to have a chat with them.

[bertwhite1]

I don't personally know of anyone taking payments through a gateway hosted on RSP. When I had my store up and running, I was setup to use PayPal, not a gateway per se, such as you would have with say an Authorize.net or other merchant account, so I don't have any experience with a gateway. Perhaps someone else will see this post and can offer their experience. I have never had any issue with RSP relative to this issue, but of course I was handing off the credit card processing to PayPal, not collecting the CC on RSP anyway. I'm currently running on a cPanel reseller account. It is very easy to install the RapidSSL certificate that RSP offers on the cPanel platform and if your are using the Hepsia control panel the process is seamless.

[yav0r]

Hello,

Maybe I can help ? What is it that you would like to know mate ?

[clivejo]

I know Paypal offers the best solution security wise, as they deal with all the sensitive information.

I'm just trying to look at the security implications of processing payments on a shared server. My client already processes telephone and postal payments via a merchant account. So processing via an API would not be a big deal. However, I'm very nervous about not having full control of the server and also other users on the server doing silly things, maybe introducing a security issue for everyone on that server. Are the servers PCI compliant?

I wanted to know if the warranty covered just the SSL connection, or the whole transaction process ie Customer > SSL > Server > Payment API > Payment Authorization or Refusal.

[yav0r]

In order to install an SSL certificate the domain (for the SSL) must reside on a Dedicated IP address. Which means the domain name or host will be entirely cut off from all other users and domain names which pretty much share the main server IP.
So in that regards you have nothing to worry about.

What you should worry about is storing credit card information on the account. This is what terrifies me, always has always will since I feel utterly helpless against hackers. We all know that if you blink a new version of the chopping cart would have been published and its probably because the old one had MySQL injection vulnerabilities or any other security holes which even the strongest SSL certificate can not protect you from.

What I always go for and suggest you customers as well is using a payment gateway to process payments/ Worldpay, 2checkout, PayPal. Sure they charge for every transaction and so on but at the end you would sleep well at night knowing that someone is not accessing a few hundred credit cards from your account right ?

[clivejo]

Yeah, this is my worry too. But my client wants to make it easy for repeat orders and therefore not have to enter credit numbers. Even if I encrypt each number before storing it in the database, the decryption key needs to be located on the server, so the script can decrypt on the fly.

The PCI guidelines say you should never store the CV3 number. I was wondering could this be used, combined with another key for example the customer account password (only the customer would know this as only a hash is stored in the database) to decrypt the credit card number. The CV3 would never be stored and once the transaction has been completed, could be destroyed. Therefore, preventing the full card number from being decrypted, by anyone but the customer. Am I making sense?

[yav0r]

The cv3 being stored or not is something that is defined from the shopping cart script but if its not stored than the automation that the client wants in order to repeat orders will be pointless as you can't process CC payments without the CV3 number. If you plan to repeat orders by the end customers and they should enter their CV3 number ONLY before checking out that could work I guess.

Any hash key which is being stored in the hosting account will also need a decryption key which must as well be located in that account so that the script may decrypt the password. Otherwise the client would not be able to login in their account in to make the payment in the first place.

My only useful though about your kind of setup would be to use WorldPay who actually not only process cards but give the user an option to create an account with them so they can shop easily and they store the CC information on their own servers so you can rest assured.

[Guest]

Yeah, this is my worry too. But my client wants to make it easy for repeat orders and therefore not have to enter credit numbers. Even if I encrypt each number before storing it in the database...

In my opinion, your client, although with good intentions, is making a huge mistake by wanting to store his customer's CC # on a server. Not only is there really no good reason for it, but by doing so, he better have a good lawyer on hand when something goes wrong because storing CC's on his server opens him up for huge liability. I would also venture to guess that if he has business liability insurance and they find out he is storing credit card #s, his rate will increase dramatically. And if he doesn't have such insurance, he should definitely not be playing with fire, like storing CC #s. And not to mention, if the **** hits the fan, you could also be mixed up in this mess since you are the purveyor of the system which stores the card #'s.

This is not a game that small businesses should bother to play. If something happens, he could lose his shirt in a heartbeat. If clients find it boring to enter CC# every time they shop online, then they can get a password manager/form filler program like Roboform and keep their card info store on their end.

As was suggested, if he wants to offer the convenience to his customers of not having to input their CC data for every purchase, then he would be better off offering paypal or another 3rd party service like that in addition to his own gateway.