cancel
Showing results for 
Search instead for 
Did you mean: 

Question on PCI Compliance ...

Hello.  I have a question on PCI compliance for my clients.  Auth.net recommend using the AIM connection method.  They claim this is the most secure method.  However, after reading the PCI self-assessment questionnaire (OHHH BOY), I am not so sure.  Basically, the AIM method seems to leave my clients more vulnerable since they are capturing the cc on their server.  Since the client server captures the cc information, doesn't the server have to be PCI compliant?  This doesn't just mean running a scan -- PCI compliant servers cost hundreds of dollars per month (per client)! 

 

Maybe I am missing something.  As I read the PCI paperwork and self-assessment questionnaire, I get the feeling the cc companies are putting so many requirements on small e-commerce businesses. 

 

What do you think?

 

Mona

focuswebtech
Member
Member
34 REPLIES 34

I'm not so sure Auth.net actually claims AIM to be the most secure. The SIM method would be more secure (assuming a sloppy developer using the AIM method) since all the client details (i.e. credit card info, etc) are being entered on Auth.net's servers directly instead of going through your servers first.

 

And someone correct me if I'm wrong but I would think that if you have no real reason to capture and record a client's CC number in your own DB, it would be best not to since it increases your risk and liability. This would at least obviate the need for you to secure credit card info since you don't store it. If you then send all the client details to Auth.net right after the client submits the info, I would think that all you would need is an SSL connection (also assuming due diligence made by the developer in terms of securing the form) to secure the data in transit and the checkout process should be solid.

Nichiren
Member
Member

I am hoping to get some good opinions here so thanks so much for your input.  This PCI compliance issue doesn't seem very straight forward.

 

Auth.net absolutely says AIM is recommended and most secure.  Check it out here:  http://developer.authorize.net/api/aim/ 

"AIM is Authorize.Net's recommended connection method and offers the most secure and flexible integration. AIM allows merchants to host their own secure payment form and send transactions to the payment gateway using an end-to-end secure sockets layer (SSL) connection. AIM is the required connection method for shopping cart developers participating in the Authorize.Net Shopping Cart Certification (SCC) program." 

 

So, I agree that ANY method CAN be bad if the developer doesn't use proper methods.  But, EVEN IF a developer uses https for the check out form, purchases an SSL, and scans their site daily, that is NOT enough to be PCI compliant (according to the PCI self-assessment questionnaire). And, those are the only things that auth.net seems to be saying are necessary.  If you read the questionnaire (or do a search for pci compliant servers), you will see that it takes ALOT of work to have a PCI compliant server.  We got a quote from www.rackspace.com of $500+ per month!

 

So ... why does it cost so much to get a "PCI compliant server," while shared hosting sites seem to think they just need an SSL and daily scanning? 

 

Confusing ...

Mona

Here is a blog post with a much better (more detailed) description of my concerns:

http://skeptikal.org/2009/05/is-mass-hosting-pci-compliant-biting.html. 

Mona

A properly coded site never records the CC in the site's database.  The CC is passed along from page to page as a form POST parameter over a (I hope!) SSL encrypted connection.  It will be in the server's memory for a time, but not in any place that an attacker could get at without a great deal of difficulty, and if they could do that, you're toast anyway.

 

One thing to watch out for, though, that recently tripped me up, is if you use a PHP cart with the default "register_globals" feature on, the POST parameters WILL be stored in the database, temporarily, in the session table.  This potentially exposes all the CC information "in the clear" to anyone who can open the database, though it is only while the customer is on a page where the CC number was passed to it as a POST parameter.  You should ensure that register_globals is off - you may need to make changes to your cart software if it depends on it being on. 

Steve

 


@focuswebtech wrote:

 

So ... why does it cost so much to get a "PCI compliant server," while shared hosting sites seem to think they just need an SSL and daily scanning? 

 

Confusing ...

Mona


 

 

Shared hosting sites don't give a flying cow about PCI compliance. They'll do the absolute minimum amount of work to be able to say they are compliant and even then they probably aren't.  Shared hosts are trying to make as much money as they can by cramming as many sites on to one server as possible. They're not really concerned about the websites any further then they need to make sure they are up so they can get paid.

 

Oh, and rackspace is way too expensive. I just migrated away all 40+ clients of ours and are now saving over $800 a month and have a server that is at least four times as powerful. I'd avoid them and look at Hostgator instead.


-------------------------------------------------------------------------------------------------------------------------------------------
John Conde :: Certified Authorize.Net Developer (Brainyminds) :: Official Authorize.Net Blogger

NEW! Handling Authorize.Net's Webhooks with PHP

Integrate Every Authorize.Net JSON API with One PHP Class (Sample code included)

Tutorials for integrating Authorize.Net with PHP: AIM, ARB, CIM, Silent Post
All About Authorize.Net's Silent Post

I don't know that shared hosting, itself, is the issue. The key with PCI compliance, at least as far as this community is concerned, is that your e-commerce site should not store any of the data that is required to be protected - primarily the Personal Account Number (credit card number, etc.) and CVV value.  If all you do is pass those values (over a SSL-protected link) to authorize.net, and make sure they are not stored on your server anywhere, ever, then you're probably ok.  (I think you need to have some protection against unauthorized access to the server and its files, but that can be done even on a shared host, unless they have serious bugs.)

 

I will agree, though, that shared hosting creates some risks.  I once used a shared host that had security holes that allowed files to be written to other user's directories.  I no longer use that host.  My client uses a managed server at 1&1, where they are the only user of that server, and that has worked well for them.  All things considered, I'd rather be on a separate server than a shared host.  Some services offer virtual hosting which, if properly done, should be ok.

Steve
hotslots132
Regular Contributor
Regular Contributor

I agree with Hotslots.  We have talked with PCI consultants about all of this PCI.  We were using AIM but decided to switch to the SIM method to get rid of some of the liability.  The SIM is limiting for us but we are PCI compliant now.  On our website, when it comes to capturing the CC info, we put ANET's page in an IFrame to submit the payment then the thank you page goes back to our website.  But if you are using AIM, the rule is you can have the CC and CVV numbers just long enough to complete the transaction, so like a split second.  If you HAVE to store anything, store the last four of the CC number not the whole thing.  But if that is the case, they want you to have your CC server AS WELL AS all other servers and networks that are connected PCI compliant also!  The thinking is that if they break into a different server on your network then they could potentially reach your server with the CC info on it.  HUGE pain.  That is why we switched to SIM and let ANET store it all.  If you can make it work without capturing it you are much better off.  If fraud happens, the credit card company will go after the bank then the bank will come after you.  If you are PCI compliant, you have a great defense.

We also use McAfee (formerly HackerSafe) for our daily scans, they are reasonably priced and can aid in finding some of your vulnerabilities.  If you have to host your site and use the SIM method along with a scan, you should be well on your way.

 


Webguys2 wrote:

We have talked with PCI consultants about all of this PCI.  We were using AIM but decided to switch to the SIM method to get rid of some of the liability.  The SIM is limiting for us but we are PCI compliant now. 

 

Right!  That is exactly what I was trying to get at in my original post.  I totally agree that it makes sense to use AIM so the liability is put on auth.net, not our clients.  However, auth.net says in its documentation that they recommend AIM as the more secure method!  Unless the client is on a PCI-compliant server in a PCI-compliant data center, that is not true.

---

But if you are using AIM, the rule is you can have the CC and CVV numbers just long enough to complete the transaction, so like a split second. 

 

Where did you see this information?  The information I read in the PCI compliance documentation and the Self-Assessment questionnaire says that any merchant that captures, stores, or transmits credit card information (even over an SSL) must be PCI compliant.  I would guess that many IT security people would say that a split second is all it takes for a hacker script to pick up the cc info.

---

If you HAVE to store anything, store the last four of the CC number not the whole thing.  But if that is the case, they want you to have your CC server AS WELL AS all other servers and networks that are connected PCI compliant also!  The thinking is that if they break into a different server on your network then they could potentially reach your server with the CC info on it.  HUGE pain. 

 

Yes, that is why I don't think you can get PCI compliance with shared hosting.  Too many vulnerabilities

 


 

 

I think many people think that an e-commerce store only needs to worry about PCI compliance if they store CC info.  I think that is a huge misconception.   Take a look here for the top 10 misconceptions:

http://www.neospire.net/business.solutions/pci.dss.misconceptions.php 

 

MC is not starting to fine some level 1, 2, and 3 merchants for non-compliance.  There doesn't even have to be a breach!  Check it out here:

http://www.storefrontbacktalk.com/securityfraud/mastercard-becomes-the-first-card-brand-to-publish-p...

 

I really believe that on-line merchants using AIM are very vulnerable for fines.  Would love to hear what auth.net has to say about that.

 

Mona