 |
|
|
Joined: 4/15/2004
Posts: 87
|
|
|
Although I understand that not only does the software need to be secure but also the web host/server the cart is running on and all systems inbetween them and the Gateway, I am curious to know what measures have/are being taken to bring the DotNetNuke Store Module up to current PCI Compliance standards?
Until recently, choosing an online shopping cart system had become increasingly difficult; there are so many shopping carts out there and until now it was usually a question of how much money does it cost, does it do what I need and does it fit my existing or new web site?
Well, our choice may have just gotten easier, according to new security standards, handling online payments in any form requires additional and very expensive certifications and audits. To this point in time, the number of hosting companies, service providers and shopping cart software developers that meet these rigorous standards is limited at best, ASPDotNetStoreFront (non-DNN version) is one and to date my favorite.
If you would like to learn more about the standards and what is required you can find them here:
http://www.mastercard.com/us/sdp/merc...
Thank you for continuing to provide a free and open source shopping cart for DotNetNuke.
|
| |
|
|
 | |
|
|
 |
Joined: 10/11/2003
Posts: 1966
|
|
|
Hi Josh,
Some weeks ago we (Team Members) have discused about PCI compliancy. Here a part of my response:
Of course, as the Store Team Leader, I'm aware of the PCI requirements. Even if I'm French we have similar standards ;-) and I think also to other countries. My source about PCI standards is the PCI Security Standards Council. Let me give some details about PCI, not for you but or those who do not know this security standard. PCI DSS standard (Data Security Standard) covers all pieces of a production system including hardware (network, firewall, ...) and server softwares (OS, Web server, db server, ...), while the PA-DSS standard (Payment Application Data Security Standard) covers only the software and mainly how are stored the card holder informations and sensitive authentication data.
To be short, the Store module have to be PA-DSS compliant. Rules are simples (please look at the PCI Security Standards Council for detail), DO NOT store any confidential customer data! The Store module follow those rules because only addresses and orders are stored. The default Gateway Providers (PayPal and Authorize) do not store any data. If you create your own provider you should follow those rules. As specified, this is not 'so simple' because to be really and fully PCI compliant, you have to audit your server, hoster material, operating system and so on. IMHO the Store module comply with PA-DSS, some other rules are covered by DotNetNuke like the authentication system. Having a store module (whatever the one you choose) with a poor hosting DO NOT give you any waranty about PCI at all: ;-)
Concerning my work on the DotNetNuke Store module, I WILL NEVER store any confidential data (credit card number, CSV code, ...) even if you or anyone ask for, period! Because I'm aware about potential security problem. :-) On the other hand, if someone can prove me that the module does not comply with a rule, I will provide a fix in days!
Gilles
We (team members) are Humans offering their knowledge, their work and their spare time FOR FREE to benefit the community. It would be so particularly appreciated that your messages begin with "Hello" and end with "Thank you" or any other form of politeness. Ask yourself what your reaction would be, if you were approached by me (a total stranger) on the street to ask you something without saying "Hello" nor "Thank you"? After several years of services dedicated to the community, I begin to be tired to read requests without any form of politeness.
|
| |
|
|
| |
|
|
|
Joined: 12/7/2006
Posts: 419
|
|
|
Hi All.
As i lead some PCI-Projects in the past i would like to give some clarification to all of you.
I would highly recommend to use a certified Payment-Module, e.g. from 1und1 (Germany)and use / implement it exactly (!) as documented.
The following list should give you the answer to your question:
- your company does not have to be PCI-DSS compliant as long as you do not store any creditcard-related data and as long as you use the above mentioned module as intended
- 1und1 must be PCI-DSS compliant, btw. they are!, as the creditcard-data will be stored / handled on their servers
- Payment Module must be PA-DSS compliant, btw. it is
Again, don't handle any CC-Data, even not with an own input dialog or something else. The only place where the customer should be able to type his cc-data in must be the Payment-Module you use.
Hope that helps
Kai
|
| |
|
|
| |
|
|
 |
Joined: 7/21/2008
Posts: 13
|
|
|
Gilles,
I've been evaluating the Store module with the intention of using Authorize.Net as the gateway. I've come to the conclusion, and correct me if I'm wrong, but due to the fact that the Store module uses Authorize.Net's advanced integration method (AIM), everything from the Store module down to the wire (software, hardware & configuration of the server, the network, etc) need to be PCI compliant because the credit card data gets sent to the Store module. And although it's not stored in a database, it get transmitted to and from my website. My hosting provider does not guarentee PCI compliance with my shared hosting account. They do offer VPS hosting with triples the hosting costs.
Again, correct me if I'm wrong, but if Authorize.Net's server integration method (SIM) were used, my website (and it's shared hosting account) would not need to be PCI Compliant because the store checkout process would move the user to Authorize.Net's website to submit the credit card data. If I'm right about all of this, is there any plans to make SIM or the newer Direct Post Method (DPM) an option?
Thank You,
Paul Bolejack
|
| |
|
|
| |
|
|
|
Joined: 10/11/2003
Posts: 1966
|
|
|
Hi Paul,
The Store module should be PA-DSS compliant even with the Authorize.Net AIM provider. Simply because customer's card data are transmitted over SSL and NOT stored on the server in any way. They live only in memory for the time of the transaction. Encrypted transaction over SSL is a requirement from Authorize, except when you use the Test Mode (in this case it's not a real transaction). Again, full PCI compliancy do not rely only to the Store module, ALL pieces of the system (hardware, OS, ASP.NET, DNN, ...) MUST be compliant. This is why it's so difficult and cost a lot. The full system must be validated by a certified specialist to be REALY PCI compliant. Moreover your system must be validated on a regular basis. Please read my first post in this thread, you can found all official documents at the PCI Security Standard Council.
You'r right about Authorize SIM and it's same with the PayPal Standard provider, because you DO NOT manage the transaction! :-)
The Store module is a simple e-commerce module with powerfull features like templating, but missing some other ones like product variants. However, it's a perfect sample of how an e-commerce module should be built. The use of providers for payment gateways, shipping and tax allow any one to create a new provider WITHOUT modify anything in the core of the module. This allow you to maintain compatibility with future versions (if the provider follow some rules). That everyone must understand, is that's is a free module and I try to provide quality support for free in this forum from more than 3 years now. To be totaly honest, I have NOT won even one cent with the Store module! This is my gift to the community because I receive a lot from others with DotNetNuke. Anyone could provide a provider or a feature, but I have enough half-hand to count those who offered something for this project.
Most of the time, it is not very complicated to create a payment provider. However, this take lot of time to test it correctly, and time is money! If I work full-time for a week, I can not charge less than 1,500$. Unfortunately, I know by experience that nobody want to pay such amount because for a quarter you can buy a full featured commercial e-commerce module!
Gilles
We (team members) are Humans offering their knowledge, their work and their spare time FOR FREE to benefit the community. It would be so particularly appreciated that your messages begin with "Hello" and end with "Thank you" or any other form of politeness. Ask yourself what your reaction would be, if you were approached by me (a total stranger) on the street to ask you something without saying "Hello" nor "Thank you"? After several years of services dedicated to the community, I begin to be tired to read requests without any form of politeness.
|
| |
|
|
| |