Shared secure cert question

alig · #1 (**permalink**) 06-12-2007, 12:16 PM

I have a shared secure cert. with my web hosting package. What I want to do is put a form on my website in the secure area that will allow my customer to send me their credit card details. I don't want to process the payment, I just want to be able to pick up the information securely.

I have used form to email before - however, I don't want this particular form info emailed to me as I believe the credit card info would not be secure? I guess the best way would be to have it sent to a database in the secure server area, but I don't know how to do that unfortunately! My question is: I have used Miva and OsCommerce before so is there something I can do with either of those programmes to access the information securely without processing the payment? I've had a look through them but at this point I am confused. Any help would be greatly appreciated...thanks.

hostBrain · #2 (**permalink**) 06-12-2007, 01:56 PM

Hi Alig,

It's good to see you're taking a pro-active stance with online security issues.
You're right in that an email form is not secure and should not be used for receiving cc info.
You might want to check out the oscommerce contributions as I believe there is one for encrypting in the database.

That said, however...
Your security acknowledgment is off-set by the fact you are using a shared ssl certificate.
Part of the reason for using an ssl certificate is to prove to the customer that you are who you say you are. The certificate displays your company name, url, address, etc.
But the shared ssl , will contain your hosts info, not yours.
Not exactly a ringing endorsement of your business.

IMO, any host that is still offering a shared ssl as if it's some kind of benefit, should be shot

alig · #3 (**permalink**) 06-12-2007, 02:30 PM

Thanks for your comments HostBrain. I've never really been comfortable with the shared cert either, I think I will bite the bullet and buy my own. It's tempting when something is free - but you get what you pay for I guess!

Looking at the Oscommerce link you suggested, I've found the following module: "Encrypting Credit Card via mcrypt - This contribution is intended to improve on the storage of the credit card number (cc_number) in the orders table."
So I'll take a further look into that.

If anyone has any further advice on a simple way to get a credit card no. stored securely without processing a payment puhleease let me know

Thanks again

hostBrain · #4 (**permalink**) 06-12-2007, 03:41 PM

Yes, good idea to get your own ssl.

With that module, you'll need mcrypt compiled into the server. You'll have to check with your host.

Shift4SMS · #5 (**permalink**) 06-12-2007, 04:03 PM

My question would be why? You mention that you want to accept CC info and you don't want to process it, only store it. Storing the info, in and of itself, is a security risk. Even encrypting it has it's weaknesses, especially on a shared server (by shared server I'm not referring to the shared SSL cert, that's an issue by itself and it sounds like you're rethinking that part).

With the current technology available, the most secure way to handle CC info is to process it online through a gateway that offers tokenization (that's what we call it, other gateways may call it something similar). Tokenization is a method where you store a token that the gateway provides in place of the cc info. As far as your application is concerned, it can use a token just like a cc without the associated risk. If a hacker or someone else sharing your server gets hold of your tokens, no problem as they are useless to anyone else. For more info, see http://www.shift4.com/pdf/TokenizationWhitePaper.pdf

If you post why, maybe I can offer some addition advice but my "rule of thumb" is to not store cc info at all.

speed · #6 (**permalink**) 06-12-2007, 04:05 PM

As you are on a shared server you need to encrypt your PHP with ionCube or Zend, without doing that someone could read the PHP to locate your encryption key and therefore negate the fact that you stored the data encrypted.

You should also probably lock he PHP script to the MAC address of the server it's running on to stop someone working on breaking your script in their own private environment, assuming they can get a copy of your script which may well be possible if the server is ever hacked.

Any time you store sensitive data you need to protect the encryption keys as if you don't you may as well not bother encrypting the data.

In my opinion anyone storing credit cards on a shared server is completely insane. If those cards numbers are stolen then you are almost certainly going to be liable for any and all costs involved. Therefore I strongly suggest you talk to the card companies about the correct way of storing the data and any liabilities before you start on this adventure.

alig · #7 (**permalink**) 06-12-2007, 04:41 PM

Thanks everyone for all the advice...
Speed, regarding your comment: "anyone storing credit cards on a shared server is completely insane. If those cards numbers are stolen then you are almost certainly going to be liable for any and all costs involved." Absolutely - this is why I am researching my options - I'm not doing anything unless it's completely secure. Sounds like there are a lot of ways for me to go wrong here though...

Shift4SMS, I will look into the tokenization a little more. This is not an ecommerce site, it's an html based site. The reason I want the credit card number sent to me securely is because we provide tourist accommodation and I get a lot of email enquiries. I respond to them and if we have rooms available, we need the guests credit card number to secure the booking. We don't charge them until they are physically on our premises and then we run it through our cc machine. At the moment we have to ask them to telephone us (some people do email the info, even though we tell them not to!).

We do have instant online booking with a third party provider and that works fine, they collect the cc info and any liability lies with them. We pay for that of course. So my query was to find out with our direct bookings if it was possible for me to get access to the cc number securely, I don't want to actually store it for any length of time. We have issues with Data Protection Act in my country that I have to follow anyway.

I often book hotels online for myself and obviously I have to put in my cc number, if I remember correctly they are charging my card right away. If you phone and give your cc number, they hold it until you check out usually.

So if the risks are too great I am not going to do down that road!
Thanks again everyone.

cppgenius · #8 (**permalink**) 06-12-2007, 04:49 PM

Quote:

Originally Posted by Shift4SMS

My question would be why? You mention that you want to accept CC info and you don't want to process it, only store it. Storing the info, in and of itself, is a security risk.

Good question Shift4SMS. I can't see any good reason why you would want to store credit card information but never use it for transaction processing. One can maybe mention a site like Amazon who stores your cc info for your convenience, but the only way they got your credit card info was during the first transaction you made with them.

I'm afraid, no person in his right state of mind is going to supply his credit card info just for simple storage by a third party. Why would you want someone to store your cc info if you are never going to do any transactions with this organisation.

Please alig, I'm not jumping to any conclusions, but I have to admit, your methods seems a bit odd. As Shift4SMS said, disclosing a bit more about why you want to do this might give us a better understanding of what you are trying to achieve.

Instead of coughing up for an SSL certificate (which is anyway going to be replaced by EV SSL in the near future), rather use a well-known and respectable secure online payment processing service to process your payments for you. It will take a huge burden from your shoulders and may even work out cheaper than a decent SSL certificate.

cppgenius · #9 (**permalink**) 06-12-2007, 04:56 PM

alig, you answered my reply even before I posted it, please ignore it. Admin, you can delete my post if you want to, looks pretty stupid doesn't it?

puamana · #10 (**permalink**) 06-12-2007, 05:18 PM

I have clients with the same issues as you - they are accommodations providers (usually bed & breakfast/small hotel or vacation rental providers).

They need the credit card information to book the accommodations. When the guest is ONSITE, you can get the info directly from them, but if the guest has not yet arrived,
and needs to have his/her reservations confirmed, the booking agent MUST have access
to credit card billing information to complete the transactions, process deposits, etc.

The problem with gateways is that the booking agent doesn't ever get to have the complete credit card information (usually just the last 4 digits). Authorize.net offers a 'recurrent billing' option, but this addresses a monthly subscription situation, not the booking agent's need to process payments at a specific time. In an 'offline' mode,
even with a shared certificate, the information needs to be written to some kind of log accessible by the booking agent.

One way I handled this was to modify a perl shopping cart (agora.cgi) to build a simple payment page. The order (including FULL credit card information) is written to an order log, for access through a management interface. These files are kept in the cgi-bin and to address security concerns, the information is .htaccess protected and the order log cleared after the cc info is retrieved. Because web access to cgi-bin files is restricted,
it's the most secure method I have found to address this issue.

Once the booking/accommodation has been fulfilled, any hard-copies are shredded.

Good Luck!
Puamana

alig · #11 (**permalink**) 06-12-2007, 05:22 PM

No problem, cppgenius, thanks for answering.

cppgenius · #12 (**permalink**) 06-12-2007, 05:31 PM

puamana, once you are done with the client's cc info, what do you do with it, do you keep it on your server, do delete the info, or do you move it to an offline/standalone computer not connected to any network?

alig · #13 (**permalink**) 06-12-2007, 05:38 PM

Puamana, your post pretty much sums up my particular problem, you explained it alot better though!

speed · #14 (**permalink**) 06-12-2007, 06:20 PM

Quote:

Originally Posted by puamana

One way I handled this was to modify a perl shopping cart (agora.cgi) to build a simple payment page. The order (including FULL credit card information) is written to an order log, for access through a management interface. These files are kept in the cgi-bin and to address security concerns, the information is .htaccess protected and the order log cleared after the cc info is retrieved. Because web access to cgi-bin files is restricted,
it's the most secure method I have found to address this issue.

But what happens if the server is hacked, how do you protect card data?

Once someone has access to the server .htaccess won't help you and if the data is encrypted but the key isn't then the data is open for the individual to steal.

mcgettrs · #15 (**permalink**) 06-12-2007, 06:31 PM

Hey Alig,
Maybe you should look into a paypal business account. They have a number of options and might suit you for this particular problem. It has been a while since i read the documentation but on a business account you pay a small precentage per transaction, rather than a subscription. One of the options they provide is that you can get users to promise you the money but it does not draw it from your customers account until you click draw funds. I am not sure does this have a time limit but it is probably worth looking into. The Paypal payment standard has loads of tools for small merchants. You can set it up to look like your site and customers don't even need a paypal account they can just enter the credit card details and you never see them or have to worry about liable but the money is guaranteed

Another idea would be to charge a small deposit using like hostelworld dot ie. Maybe use paypal to charge 10% of the nightly cost and take that money straight away and then charge the rest when your customers come using the machine in your lobby.

I hope this helps. I am working on a small tourism site in the west of ireland too and paypal really worked wonders for me

alig · #16 (**permalink**) 06-12-2007, 08:00 PM

Hi mcgettrs - yes, I've set up paypal on another site that sells books and that's working fine for them. Generally the reason we want the credit card is for no-shows i.e. if someone books a bed and just doesn't show up we charge the first nights accommodation. If we did the 10% deposit thing that might lead to a lot of refunding (we have a cancellation policy and if you cancel within a certain time period you would get the deposit back). I wonder is refunding money easy via Paypal. I will check into that.

The third party online booking service we use actually is hostelworld... but I was looking for a way to bypass them and their fees. Most of my bookings come via email enquiries from my own website. I think I need to compare the costs and see what the difference is. Some good suggestions there, thanks.
Have a great summer - the west is the best!

DrTandem1 · #17 (**permalink**) 06-12-2007, 09:32 PM

I'm not sure why you are re-inventing the wheel. Why not let a third party do this for you? Try a free shopping cart from a service such as Mal's e-commerce. The credit card information is stored securely on their server. You are emailed only a notice to log into their server and retrieve the information. You can set the "cart" up so that the items are free. That way, there is no cost to your visitors and no cost for you.

Shift4SMS · #18 (**permalink**) 06-14-2007, 01:08 PM

Quote:

Originally Posted by puamana

I have clients with the same issues as you - they are accommodations providers (usually bed & breakfast/small hotel or vacation rental providers).

They need the credit card information to book the accommodations. When the guest is ONSITE, you can get the info directly from them, but if the guest has not yet arrived,
and needs to have his/her reservations confirmed, the booking agent MUST have access
to credit card billing information to complete the transactions, process deposits, etc.

The problem with gateways is that the booking agent doesn't ever get to have the complete credit card information (usually just the last 4 digits)...

Puamana & alig,

At a minimum, I my recommendation would be to perform a $1 authorization at the time of the reservation request. I'm not sure about Authorize.net's version of a token, but some gateway tokens

can be used by multiple applications. The online system can accept the cc, perform the online auth, if approved the token can be sent to the booking system and it can use the token just like a cc when the room is booked.

Now alig's situation is a little different. No charge is made to the card until the guest check's in. Here, I would not use the cc information used for the reservation and instead require the physical card to be swiped. This give the merchant a much better discount rate and much better charge back defense. In this case the cc information used for the reservation would only be used in the event of a no-show. Again, the token can be used just like a cc.

Shift4SMS · #19 (**permalink**) 06-14-2007, 01:17 PM

Quote:

Originally Posted by DrTandem1

I'm not sure why you are re-inventing the wheel. Why not let a third party do this for you? Try a free shopping cart from a service such as Mal's e-commerce. The credit card information is stored securely on their server. You are emailed only a notice to log into their server and retrieve the information. You can set the "cart" up so that the items are free. That way, there is no cost to your visitors and no cost for you.

I'm not sure you are picking up on the subtle difference between reservation/booking/check-in and "traditional" ecommerce - these issues are not addressed by most shopping carts or gateways. The only reason I know about this stuff is that close to 50% of the transactions we process are for hospitality merchants (restaurant, hotel & time share) and I know their issues are unique. I will check out Mal's offering but I have serious doubt they can handle these issues and I know Paypal cannot.