 |
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
 Posted: Tue Nov 11, 2008 6:04 pm
PCI Compliance and PHP4
|
So, what am I spending my time doing these days? Working on the new mapper? I wish. No, I'm wasting my time with all of this PCI Compliance crap.
Now, I understand the need for computer and network security as much as anyone. But I'm really getting tired of some of these rules that are being forced down upon us. It's all an attempt to force out small businesses and get us to pay someone else to do all of our processing.
What I just learned that caused me to blow up was that any site that runs PHP4 is no longer PCI compliant...period. Don't give me arbitrary "you must upgrade your software" crap like this! There isn't anything wrong with the latest version of PHP4. If you find a security hole in it, then tell me what the hole is and I'll fix it. Don't just tell me to upgrade my software.
Do you know how long it will take me to update this site to use PHP5??? Weeks. Weeks of time that I can't use to work on stuff that matters like my own products. Just to please some automated compliance checker.
Because the problem is that it doesn't just check our ecommerce store. It checks the entire site. So if we run PHP4 for our Forums, or our Knowledge base, or our Blogs, then that causes the entire site to fail PCI compliance.
What this forces people to do is to move all of their ecommerce off to some other big company site and pay them to do it. Because then it's scanning *their* site and not mine. For example, we stop handling credit cards ourselves and just force all of our customers to buy our products via PayPal. Which would then cause us to lose the business of those customers who don't want to use PayPal.
I don't really know at this point what I'm going to do about this mess. I'm still fuming mad about all of it. My site passes the other PCI Compliance tests, but just because I run PHP4, I'm going to need to spend weeks and weeks trying to fix all of this site for PHP5. A total waste of my time.
Yes, I agree that everyone should be using PHP5 for *new* products. I understand that PHP4 is no longer being supported or patched. But to just force everyone to upgrade all of their web apps from PHP4 to PHP5 is just ridiculous. |
|
|
|
|
Tech
GURU
Joined: 18 Oct 2000
Posts: 2733
Location: Atlanta, USA
|
Posted: Tue Nov 11, 2008 11:39 pm
|
It's kind of kludgy, but a stop gap measure may be to put the store on it's own web domain so that it's only one that's checked. But you are right, that would suck BIG time. Not just for the hassle of how it was brought about, but also the forced (and almost guaranteed to be rushed) site conversion. Yes, somethings may go a little faster having just done SlightlyMorbid.com but all in it will be a massive undertaking.
Not to mention those of us who have been salivating for a 3.01 version BETA and to a lesser degree those who may be concerned that you may be getting distracted and not focused on CMUD. Hopefully you find a nice clean way around it. |
|
_________________
Asati di tempari! |
 |
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Wed Nov 12, 2008 1:28 am
|
It's not just putting it on it's own web domain...it requires putting it on a completely different hardware box. PCI compliance requires that the entire computer be compliant. Yes, it's a *real pain* for people using shared hosting. Basically your web hosting company ends up having to follow PCI rules too. It's a mess.
And no, there wouldn't really be any way for them to "know" if it's on the same box or not, but that's not the point. It's a risk that I take by not being compliant. If something bad happened, VISA could fine me $50,000 and I'd lose my merchant account if I couldn't *prove* that I was PCI compliant. So I can't really play any games with virtual hosts.
The similar solution is what I already mentioned...I could just disable my own credit card processing and force everyone to use PayPal. But I don't really want to do that and don't want to lose the sales that it would cause. So for now it's just a risk vs benefit issue.
Anyway, as I mentioned in my CMUD Beta post, I am *not* going to let this distract me from the mapper beta...it's just too important for me to not delay that. So I'm going to get the new beta version out and then work on the web site after the holidays. Then I'll take the time to do the site correctly and not rush it. Having just done SlightlyMorbid *does* prepare me for doing this, along with all the testing of various PHP IDE tools, etc. But as you said, it will still be a massive undertaking. I've given it some thought and I think it would take just as long to upgrade all of the various components (PHPBB, MX-Portal, XCart, etc) and then re-customize it all as it would to just write everything from scratch myself using PHP and CodeIgniter. And the advantage of doing it myself is that I'll be able to more easily do everything exactly how we all want it to be done and no longer use the excuse that "PHPBB doesn't do that, sorry". Also, it will be easier to maintain in the future if it's my own code without worrying about upgrading all of the components all the time. So that's the direction I'm leaning. |
|
|
|
|
Rorso
Wizard
Joined: 14 Oct 2000
Posts: 1368
|
Posted: Wed Nov 12, 2008 5:32 pm Re: PCI Compliance and PHP4
|
They should fix the insecure credit card system. Isn't it mainly the credit card number you need and then you can shop away? If it is then it does not sound like a very secure design at all. Someone who is using a card would have many potential number thieves. Can you trust the shop clerks?
Is using latest PHP required by the standard? What if you were using some home brewed PHP interpreter or even Pascal interpreter? What if you hosted some other service, e.g a MUD server? |
|
|
|
|
Fang Xianfu
GURU
Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom
|
Posted: Wed Nov 12, 2008 5:40 pm Re: PCI Compliance and PHP4
|
| Rorso wrote: |
| What if you were using some home brewed PHP interpreter or even Pascal interpreter? What if you hosted some other service, e.g a MUD server? |
I expect the answer to those questions is "You're stuffed". If they're willing to do it to people running real, legitimage PHP4 you can bet they'll do it to people doing something more esoteric. |
|
|
|
|
Rorso
Wizard
Joined: 14 Oct 2000
Posts: 1368
|
Posted: Wed Nov 12, 2008 5:59 pm Re: PCI Compliance and PHP4
|
| Fang Xianfu wrote: |
I expect the answer to those questions is "You're stuffed". If they're willing to do it to people running real, legitimage PHP4 you can bet they'll do it to people doing something more esoteric. |
How do they do it though? Is really the website the only thing that needs to be certified?
What about cMUD/zMUD which both connect to the Internet. Can we be sure that someone has not planted a Trojan horse into the shareware executable? For example on Silverbridge.org we host a copy of the latest versions of both clients. Some more dishonest person could easily implement keylogger and add it to the clients, and then when someone go to buy the client it would send out the needed information.
SSL clearly does not help in this case. Antivirus does not help if it is a new threat. Firewall does not help because you expect to be able to connect to play MUDs, and there is absolutely nothing the user could do. It could even be possible to get it into the official version on the official website, using social manipulation and fool Zugg to run something he probably shouldn't. The system is simply completely insecure. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Wed Nov 12, 2008 8:44 pm
|
| Quote: |
| Can you trust the shop clerks? |
Exactly!! When our credit card was stolen several years ago, it was traced to a local restaurant. Had nothing to do with "online security". My guess is that this is all a reaction to the incident several years ago where some large online vendors were hacked and they were storing credit cards, so a large number of credit card numbers got stolen in the process. So because those vendors had poor security, we are now all paying for it, even though the real problem will remain with the live cards themselves.
| Quote: |
| What if you were using some home brewed PHP interpreter or even Pascal interpreter? What if you hosted some other service, e.g a MUD server? |
In that case, you cannot get a merchant account to process credit cards yourself. Or, if your merchant vendor finds out about it, they can immediately cancel your merchant account. When you sign up for a merchant account these days, you have to sign stuff that says you will comply with Visa/Mastercard requirements (or whatever credit cards you process).
It applies to not just my own web site, but any web site that I transfer the credit card information to. I'm required to only work with other companies that are also PCI Compliant. For example, after collecting the credit card data for purchasing CMUD, it gets sent to the Verisign site (now owned by PayPal) for actual processing. Thus, the Verisign site also needs to be PCI Compliant (which they are).
For large merchants, this is enforced via regular audits. For example, if I was a large company doing a lot of credit card transactions online, then I would be visited by auditors on a yearly basis who would inspect all of my computer systems to determine what I was doing and to ensure compliance. For a small business like Zuggsoft, I don't need to have any live inspections or audits, I just have to fill out forms and sign my name to certify that our systems are in compliance. If something bad happens and they audit me and determine that I was *not* in compliance, then I get a large fine and get my merchant account canceled.
All we are talking about here is security requirements imposed by the credit card companies. That is what "PCI Compliance" is. It's a set of rules developed by Visa/Mastercard. They require any merchant that processes those cards to adhere to their rules.
So this doesn't have anything to do with general computer security. It has nothing to do with security of software like CMUD. It only applies to a computer system that accepts specific credit card numbers. They require that computer to use specific versions of SSL, web servers, application software (like PHP), database software, etc, to ensure that the credit card given by the customer does not get compromised in any way by the merchant web site. The purpose is to try and increase consumer confidence in doing online business. Even though online business is already *much* more secure than normal local merchants that see and process your physical card.
| Quote: |
| Some more dishonest person could easily implement keylogger and add it to the clients, and then when someone go to buy the client it would send out the needed information. |
That is actually why I tell everyone to *only* download software from the "official" site. Not just for zMUD/CMUD, but for any software. I never download software that has been copied to some other site unless I really trust that site for some reason. Because like you said, there's nothing stopping anyone from wrapping *any* software in a trojan horse. Although in the specific case of zMUD/CMUD, our Armadillo copy protection would prevent that since it can't be decrypted if it's wrapped in some other wrapper. But a lot of software doesn't have that protection.
But it's good to be paranoid. I'm very careful about what Browser plugins I add to Firefox, for example. It would be pretty easy to write a plugin that captured information that you enter into web forms and store it or send it to some other site.
| Quote: |
| It could even be possible to get it into the official version on the official website |
That is actually highly unlikely. That would require me to run something as root on the server, and I just never do that. I get all of my software (such as Apache, MySQL, PHP, etc) that I install or update on the server only from official sources.
| Quote: |
| The system is simply completely insecure. |
No, I don't agree with that. As I've said, I think the online situation is actually more secure than your local restaurant. |
|
|
|
|
Rorso
Wizard
Joined: 14 Oct 2000
Posts: 1368
|
Posted: Wed Nov 12, 2008 9:14 pm
|
| Zugg wrote: |
| Quote: |
| It could even be possible to get it into the official version on the official website |
That is actually highly unlikely. That would require me to run something as root on the server, and I just never do that. I get all of my software (such as Apache, MySQL, PHP, etc) that I install or update on the server only from official sources.
|
Actually what I meant is that if someone fooled you to get a keylogger into your work Windows PC, then when you login using e.g Putty to the server they would see the password as you type it. A firewall that protects against outgoing connections probably could prevent that though.
| Quote: |
| Quote: |
| The system is simply completely insecure. |
No, I don't agree with that. As I've said, I think the online situation is actually more secure than your local restaurant. |
It could be even more secure though using for example use once passwords. E.g you have some function F(x) on you. Then the server sends you 'x'. You calculate F(x) and send that as reply. If the server, who also knows F(x), can match the data it would count as valid. After 'x' has been used once the server would never ask for that particular input again. You could have this on a read only chip on the card, so the card itself would do the calculation while in some card reader.
Something I would like to see as well is the ability for allowing/disallowing transfers. E.g you use cell phone or Internet to move funds to different buckets. For example you could move $20 to the Zuggsoft bucket, which means Zuggsoft would be allowed to withdraw that money once the customer wants to buy something. If no money is in the bucket then the transfer would be disallowed. |
|
|
|
|
ralgith
Sorcerer
Joined: 13 Jan 2006
Posts: 715
|
Posted: Thu Nov 13, 2008 2:37 am
|
WOW. Every time I read about the changes to the PCIComp, I want to puke. This is why I do only accept credit cards via paypal. And it does make it harder. Sigh, I feel for ya Zugg. But that's bureaucratic stupidity for you.
|
|
_________________
 CrossOver: Windows Compatibility on Mac and Linux CMUD Advocate |
|
|
|
Castaway
GURU
Joined: 10 Oct 2000
Posts: 793
Location: Swindon, England
|
Posted: Wed Dec 17, 2008 8:17 am Re: PCI Compliance and PHP4
|
| Zugg wrote: |
What this forces people to do is to move all of their ecommerce off to some other big company site and pay them to do it. Because then it's scanning *their* site and not mine. For example, we stop handling credit cards ourselves and just force all of our customers to buy our products via PayPal. Which would then cause us to lose the business of those customers who don't want to use PayPal.
|
I'm a bit late to the party but, why only mention Paypal? What about worldpay, bmtmicro and all those other "do real CC processing for you" companies? Paypal is not the only option. How much do the others cost? Is it less than the effort of fixing up your site?
Sure, integrating one of those costs time too, but likely less than fixing up your entire site, and probably less hassle in the long run. Use blackboxes, don't maintain a bunch of your own, its not worth it IMO.
C. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Wed Dec 17, 2008 5:40 pm
|
The others cost far more than Paypal and more than doing it myself. I have used other processors in the past and they all have various problems. I used ShareIt for a long time. Most of them are being bought up by Digital River these days. But in all cases they cost me several hundred dollars per month that I cannot afford.
|
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Thu Jan 15, 2009 8:19 pm
|
Now that we have moved to a new server, I have more flexibility running PHP4 and PHP5 on the same server. So today I was playing with setting up a PHP5 test site.
However, there is apparently a bug in the CGI version of PHP5 that ignores the setting of "display_errors" in the PHP.INI file. I have a file with a Notice "error" in it. This Notice error is displayed in the browser, even when display_errors = Off. I have set:
error_reporting = E_ALL & ~E_NOTICE
display_errors = Off
and I have verified using phpinfo() that these values are set properly. But even when set properly, the errors are still displayed. I have found several reports via Google that seem to confirm this problem in the PHP5 CGI version (see: http://bugs.php.net/bug.php?id=44729), but have yet to see this bug accepted by the PHP developers. It's not just a problem in the Windows server...the problem exists in the CGI version on CentOS 5.2 also.
As a work around, I had to add this to the beginning of my scripts:
| Code: |
$errorlevel=error_reporting();
error_reporting($errorlevel & ~E_NOTICE); |
which will turn off Notice reporting no matter what the current error level is. This seems to work. Also, just doing:
error_reporting(0);
seems to properly turn off error reporting. I have no idea why this works with the error_reporting function, but not with the PHP.INI file.
But this is EXACTLY the kind of problem I have with being FORCED to upgrade to PHP5. This is a huge security hole! Turning off PHP error reporting is one of the main things that you do in a production environment to prevent any errors from giving hackers clues to your scripts. In fact, PCI Compliance requires that PHP errors be turned off. And yet PHP5 has this bug that makes it very difficult to turn off errors using the normal INI file.
This bug has been reported in many other places for several months, and yet it hasn't gotten fixed yet. Is that what we can expect from the "supported" version of PHP? Just goes to show that PCI Compliance has little to do with actual site security. Especially since the PCI Compliance testing program only checks the value of the PHP.INI and not whether PHP errors are *really* turned off. |
|
|
|
|
ralgith
Sorcerer
Joined: 13 Jan 2006
Posts: 715
|
Posted: Fri Jan 16, 2009 8:05 pm
|
Dumb question, but... does it only affect it when run via CGI? What about if you run it using mod_php5? (Yes I know thats not possible on the production server right now, but I thought I'd ask)
|
|
_________________
CrossOver: Windows Compatibility on Mac and Linux CMUD Advocate |
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Fri Jan 16, 2009 8:16 pm
|
Yeah, I haven't been able to test that because the new server is live right now. In a few months when the site is all converted to PHP5 and I switch from the FCGI to the mod_php5, then I'll be able to try it and let you know. But according to the PHP Bug link that I gave in the previous post, other people have reported that it only seems to effect the CGI version, which I think is why so few people have this problem.
|
|
|
|
|
ralgith
Sorcerer
Joined: 13 Jan 2006
Posts: 715
|
Posted: Sun Jan 18, 2009 8:34 pm
|
Ok, so most likely its in the conversion code that takes the CGI input and hits it into the php daemon. Ick. :) Anyways, I'm setting up a testing site for one of my projects at home, and its on a machine with PHP5, so I'll be able to see shortly myself. Was just wondering if you knew. Thanks.
|
|
_________________
CrossOver: Windows Compatibility on Mac and Linux CMUD Advocate |
|
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
