RE: [PHP] Secure monetary transactions
From: Paul M Foster I'm certain people on this list have set up this type of system for customers. So I have some questions: 1) Does the usual online store software (osCommerce or whatever) include secure pages for acceptance of credit cards? I know they have the capability to pass this info securely off to places like authorize.net for processing. 2) Assuming a customer website, probably hosted in a shared hosting environment, with appropriate ecommerce store software, how does one deal with PCI compliance? I mean, the customer would have no control over the data center where the site is hosted. Moreover, they would probably have little control over the updating of insecure software, as demanded by PCI. They likely don't have the facilities to do the type of penetration testing PCI wants. So how could they (or how do you) deal with the potentially hundreds of questions the PCI questionnaire asks about all this stuff? How do you, as a programmer doing this for a customer, handle this? 1) No. 2) PCI compliance is neither simple nor cheap. If you have not done it before, hire a consultant that has and have them train you. You will also need annual refresher courses and a good auditor to validate your site every month. You will need to change data centers, as you need one that is PCI compliant for the pages that will handle protected information. There are requirements for physical security of those servers as well as the software that runs on them. You also have a choice of maintaining your own servers or finding a managed hosting service that will maintain them for you. One of the requirements is that you must maintain separate servers for development and testing. You also need to establish a formal development, test and deployment process. The developers are not allowed to have any access to the production servers. We have four sets, development, QA test, User Acceptance Test and production. The latter two are exposed to the Internet, while the first two are internal only. We have several sites that are now PCI compliant. It took us eight months after the decision to get the first one online and certified. Most of that was training and waiting for the audits and certification, as we nearly passed the initial validation on the first try. But we had to change hosting providers twice to find one that we were comfortable with. After that is all said and done, keep in mind that the primary purpose of the PCI requirements is to mitigate the financial liability of the credit card issuers. If anything goes wrong at your end that exposes privileged data, you will be financially responsible for the damages. So make sure you go above and beyond those requirements to protect yourself. Bob McConnell -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Secure monetary transactions
On Tue, Feb 8, 2011 at 8:29 AM, Bob McConnell r...@cbord.com wrote: From: Paul M Foster I'm certain people on this list have set up this type of system for customers. So I have some questions: 1) Does the usual online store software (osCommerce or whatever) include secure pages for acceptance of credit cards? I know they have the capability to pass this info securely off to places like authorize.net for processing. 2) Assuming a customer website, probably hosted in a shared hosting environment, with appropriate ecommerce store software, how does one deal with PCI compliance? I mean, the customer would have no control over the data center where the site is hosted. Moreover, they would probably have little control over the updating of insecure software, as demanded by PCI. They likely don't have the facilities to do the type of penetration testing PCI wants. So how could they (or how do you) deal with the potentially hundreds of questions the PCI questionnaire asks about all this stuff? How do you, as a programmer doing this for a customer, handle this? 1) No. 2) PCI compliance is neither simple nor cheap. If you have not done it before, hire a consultant that has and have them train you. You will also need annual refresher courses and a good auditor to validate your site every month. You will need to change data centers, as you need one that is PCI compliant for the pages that will handle protected information. There are requirements for physical security of those servers as well as the software that runs on them. You also have a choice of maintaining your own servers or finding a managed hosting service that will maintain them for you. One of the requirements is that you must maintain separate servers for development and testing. You also need to establish a formal development, test and deployment process. The developers are not allowed to have any access to the production servers. We have four sets, development, QA test, User Acceptance Test and production. The latter two are exposed to the Internet, while the first two are internal only. We have several sites that are now PCI compliant. It took us eight months after the decision to get the first one online and certified. Most of that was training and waiting for the audits and certification, as we nearly passed the initial validation on the first try. But we had to change hosting providers twice to find one that we were comfortable with. After that is all said and done, keep in mind that the primary purpose of the PCI requirements is to mitigate the financial liability of the credit card issuers. If anything goes wrong at your end that exposes privileged data, you will be financially responsible for the damages. So make sure you go above and beyond those requirements to protect yourself. Bob McConnell 1. The client is responsible for the procurement of the hardware, and software they want used. 2. Programmers are to live in a secure environment where reliable technologies are introduced in order for them to develop with. 3. The client is always right, so they're always to blame as well, according to their own procured wisdom. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- According to theoretical physics, the division of spatial intervals as the universe evolves gives rise to the fact that in another timeline, your interdimensional counterpart received helpful advice from me...so be eternally pleased for them. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Secure monetary transactions
Paul M Foster wrote: [snip] In essence, my customer is not responsible for any confidential/secure information, which is all handled by the merchant gateway. For whatever unknown reason, my customer has been convinced they should go with a different merchant service company. However, this company doesn't have the same kind of secure payment pages. (Yes, they're legitimate, but they're simply a payment processor. They don't have the additional site to accept manual input of payment information and such.) I've explained to my customer that, in doing this, he will need: [snip] I've done quite many of these... all of which could be questionable as to PCI-compliance... however, first, why you would require an ecommerce app? Most gateweways come with an SDK with examples that you can start from. For PCI compliance, go through the steps at the link Gary posted and see where (if any) there become issues. Very basically, never store the credit card, encrypt it always, and I don't see a reason why this could not be done securely as long as your shared environment is secured. If your shared environment is not secure and you require PCI compliance, tell them they need to go to a VPS or something... about the same pricing. Donovan -- D Brooke -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Secure monetary transactions
(Sorry-- originally sent without subject.) I have a customer who currently has his site set up this way: donors select (on a non-secure page) the level of donation they want to donate, provide their name and an attestation, etc. None of the data confidential. Then they press the button, and we send them off to a secure payment gateway operated by the merchant service company. They take down the credit card and other information, clear the transaction, and pass the approval/disapproval info back to my customer's website. An email then gets fired to my customer containing all the data about the transactions EXCEPT the confidential information, like credit card number, etc. In essence, my customer is not responsible for any confidential/secure information, which is all handled by the merchant gateway. For whatever unknown reason, my customer has been convinced they should go with a different merchant service company. However, this company doesn't have the same kind of secure payment pages. (Yes, they're legitimate, but they're simply a payment processor. They don't have the additional site to accept manual input of payment information and such.) I've explained to my customer that, in doing this, he will need: 1) a fixed IP ($) 2) a security certificate ($) 3) an online store (as opposed to a single page he has now) 4) a whole new set of PCI responsibilities which his organization is not prepared to fulfill. ($) I'm certain people on this list have set up this type of system for customers. So I have some questions: 1) Does the usual online store software (osCommerce or whatever) include secure pages for acceptance of credit cards? I know they have the capability to pass this info securely off to places like authorize.net for processing. 2) Assuming a customer website, probably hosted in a shared hosting environment, with appropriate ecommerce store software, how does one deal with PCI compliance? I mean, the customer would have no control over the data center where the site is hosted. Moreover, they would probably have little control over the updating of insecure software, as demanded by PCI. They likely don't have the facilities to do the type of penetration testing PCI wants. So how could they (or how do you) deal with the potentially hundreds of questions the PCI questionnaire asks about all this stuff? How do you, as a programmer doing this for a customer, handle this? Paul -- Paul M. Foster http://noferblatz.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Secure monetary transactions
On Mon, Feb 7, 2011 at 2:06 PM, Paul M Foster pa...@quillandmouse.com wrote: (Sorry-- originally sent without subject.) I have a customer who currently has his site set up this way: donors select (on a non-secure page) the level of donation they want to donate, provide their name and an attestation, etc. None of the data confidential. Then they press the button, and we send them off to a secure payment gateway operated by the merchant service company. They take down the credit card and other information, clear the transaction, and pass the approval/disapproval info back to my customer's website. An email then gets fired to my customer containing all the data about the transactions EXCEPT the confidential information, like credit card number, etc. In essence, my customer is not responsible for any confidential/secure information, which is all handled by the merchant gateway. For whatever unknown reason, my customer has been convinced they should go with a different merchant service company. However, this company doesn't have the same kind of secure payment pages. (Yes, they're legitimate, but they're simply a payment processor. They don't have the additional site to accept manual input of payment information and such.) I've explained to my customer that, in doing this, he will need: 1) a fixed IP ($) 2) a security certificate ($) 3) an online store (as opposed to a single page he has now) 4) a whole new set of PCI responsibilities which his organization is not prepared to fulfill. ($) I'm certain people on this list have set up this type of system for customers. So I have some questions: 1) Does the usual online store software (osCommerce or whatever) include secure pages for acceptance of credit cards? I know they have the capability to pass this info securely off to places like authorize.net for processing. 2) Assuming a customer website, probably hosted in a shared hosting environment, with appropriate ecommerce store software, how does one deal with PCI compliance? I mean, the customer would have no control over the data center where the site is hosted. Moreover, they would probably have little control over the updating of insecure software, as demanded by PCI. They likely don't have the facilities to do the type of penetration testing PCI wants. So how could they (or how do you) deal with the potentially hundreds of questions the PCI questionnaire asks about all this stuff? How do you, as a programmer doing this for a customer, handle this? Paul -- Paul M. Foster http://noferblatz.com Paul, From what I remember of doing PCI compliance a few years back, compliance requires control over the environment (software applications, servers, network, back end storage ie. SQL server, other sites/facilities connected on the company WAN, etc). Everything within the said environment has be secure (including the encryption of PI storage), limited access, and auditing mechanism of all access and changes within the said environment, including constant rotating password/code (logon authentication, code to server room, etc.) where use of past password/code is prohibited. So for your 2nd question, as a programmer, you could do something about the application. For the rest, you'll have to find a hosting provider that already qualified for PCI or your client/boss will have to host it themselves and qualify for PCI. I think the former would be hard to find. The latter will most likely be costly and very time consuming if the need is immediate. Regards, Tommy -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
