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?
Of course AIM is in the scope of PCI. However, hosting is virtually never "hacked" into - it's always people leaving their passwords lying around or installing trojans that's the problem. Any major hoster with partitioned hosting (virtual server) should be sufficient, for instance I use "virtual dedicated hosting" with Godaddy for $35 / month. Shared hosting is much more hackable from the inside, though it's unlikely hackers will be on your particular server.
More of a problem is computer security. If you're on a network, and any computer on the network is compromised, yours could theoretically be as well. Browsing some areas of the Internet or installing certain programs can be dangerous too. Essentially, you need good virus protection software and you need to stay away from Internet Explorer, either that or you need to use a Mac. You also shouldn't be networked to any other computer that doesn't follow at least as stringent security requirements as your own.
And of course, if your passwords are written down anywhere, either on paper or on your computer, you need procedures in place to make sure that only you or people you trust implicitly have access to the passwords. If you throw out an unshredded piece of paper with a password on it, or leave your laptop lying around at a party, you have to assume someone's going to take advantage of you.
Short version - don't worry too much about hosting security, as long as you're not setting up and running the server yourself. Worry about computer and password security.
First of all - This isn't aimed at anyone in particular.
Secondly - I'm not a lawyer, PCI expert, or security consultant - so take everything I write with a pinch of salt.
I'm 99.999% sure that by using AIM you will need to be PCI compliant.
No hosting provider I know of, whether they provide shared, virtual/cloud-based or dedicated servers, is going to assume liability from you unless you're paying $$$ (that pays for their insurance).They may go as far as saying their infrastructure is PCI compliant, or their products are PCI compliant, but they will not assume liability from you - because they don't control your site/software.
Saying that, *I think* you can mitigate a lot of the risk by reading the appropriate documents at the PCI standards site: https://www.pcisecuritystandards.org - lots of these requirements are just plain common sense and failing to implement simple things like SSL security, strict access-control, secure programming methodologies, not storing CC info etc.. will land you in a very nasty place - and courts take a very dim view when you don't implement something that is commonplace/well known.
And of course, if you need to - hire a professional.
Just my 2c.
I just think all this fear over PCI is overblown. You'd be surprised how many sites are getting away with truly horrible security flaws and nothing ever happens to them, so if you make a good-faith effort to implement as much of the security requirements as possible, I don't think you're going to get lined up and shot because you don't have a 50-page security procedure for handling password security. Almost all credit card leaks are from personal computers with trojans installed, not the sites those computers are buying from.
Funny fact - ISP's can easily determine which customers are infected with worms and so on and turn off their Internet access. Problem is, these customers then all call the ISP's phone number instead of fixing the problem on their own, so this incurs extra cost for the ISP's and the ISP's therefore just leave them turned on and infecting / spamming everyone else.
I'm willing to bet that 90% of business taking credit cards [offline] aren't PCI compliant, because 90% of transactions probably go through small businesses where there's many people working for minimum wage who couldn't give a hoot about your credit card details.
PCI is over rated but if you want a host that helps in anyway they can I recommend Host 99 http://www.host-99.com they take PCI to another level and do everything they can with their partners to get you passed. They also have specials for hosted customers to make scanning services affordable even if you are with a vendor already signed through your processor they can get it set up where you pay less then $125.00 a year for scanning and offer support same time.
Resources: Hosted there for two years.. :) No problems since
I wanted to make 2 comments on PCI:
1. I think at this point it's still largely an "insurance policy" for the credit card companies - they aren't enforcing it (I've had few ecommerce clients ever mention if to me), but if fraud occurs, they can pull it out and penalize the merchant for not being PCI compliant. Maybe at some point this will change, and they will ramp up proactive enforcement.
2. Regardless of what solution you use for payments, it seems the key is that you still need to "document" what you are doing, through scans, questionaires, etc. It's not enough to use SIM or DPM, and say "ok, we're good". Likewise if you use AIM - simply claiming your coding and server are PCI compliant is not enough - you need to go through the steps to document that.
Still trying to get a handle on how to best approach this topic with my clients. Many of my clients are small merchants / hobbyists who can afford hundreds of $$ / year to maintain compliance.
There will be no credit card leaks using Authorize.net unless someone gets into the hosting. The safety of the hosting is entirely dependent on the client keeping his passwords safe. Therefore, it's not your problem. Just go over some basics of password and computer security and make sure that the contract covers you against anything bad that might happen. A few hundred dollars doesn't buy the client fully-documented PCI compliance, just a good-faith effort to make things as secure as possible against credit card leaks.
As I've said before, most "hacking" is really just people losing their passwords or having them stolen by way of trojans. You're only responsible for what you do, not what the client does.
DPM (or "Hosted CIM"-- not regular CIM) are the two best methods for keeping your system out of scope for PCI while giving you full control over the user experience to the customer.
The reason DPM exists is to be the successor to AIM. Auth.net is already pushing DPM and they make it clear on their comparison chart that it is preferable to AIM. See the "Data Storage" row, near the bottom, of their comparison.
I bet that in another couple of years they'll be referring to AIM as a "legacy" api. As well they should. DPM is clearly a superior api, when considered from the whole-system point of view.
Re PCI compliance enforcement -- for the past several years, I've consistently seen merchant account providers require PCI compliance. They usually outsource to a 3rd party. You talk with them on the phone about your set up and they then determine which type of assessment is required for your business. The assessment process also depends on your $ volume.
And if you don't make time or priority to talk to the telephone assessor, then the merchant account provider eventually starts charging a PCI non-compliance fee. Evalon charged one of my clients $25 per month.
Because of the above, all of my future Auth.net work will be either DPM or Hosted CIM.
I personally dislike any system that requires forwarding the user - even more or less invisibly - to a third-party site for their credit card charging. Until such time as PCI compliance involves lining up and shooting people who are collecting credit card info using SSL, I will continue to collect credit card info using SSL, and I'll avoid any merchant system that eliminates the ability for me to do so. There are dozens of other systems out there I can use instead if Authorize.net decides to kill AIM.
As I keep saying, if a hacker gains access to your hosting, you're screwed. Period. No amount of security on your merchant integration is going to stop someone who's inside your account. All you might manage to do is delay them a few extra minutes. So what exactly is the point of PCI, aside from scaring companies away from doing obviously stupid things like keeping credit card numbers in publicly-accessable text files? PCI is mostly like wearing a fig leaf.