New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeOur CommunityOur CommunityGeneral Discuss...General Discuss...PCI - DSS: Will DNN be compliant?PCI - DSS: Will DNN be compliant?
Previous
 
Next
New Post
5/8/2009 5:39 PM
 

All ecommerce sites that process credit/debit cards will need to be PCI DSS compliant by Oct 09 at the LATEST. Currently, DNN's lack of certifiaction means that any storefront software running on DNN (aspdnsf, catalook etc.) will not be compliant unless DNN is certified.

This means that I will be unable to trade after October this year unless a certified version of DNN is released, allowing enough time for the software vendors to get their products subsequently certified too.

Can someone from DNN Corp please respond and provide details of what is happening with this?

 

Thanks

 
New Post
5/8/2009 8:42 PM
 

I had a look at wikipedia about this - doesn't this relate to how you store people's credit cards on your server - sorry if I seem very ignorant about this - but I am interested in knowing more.

http://en.wikipedia.org/wiki/PCI_DSS

I would have thought this would relate to how people store customer credit cards on their server - but if you adopt the policy of many people, and NOT store credit cards on the server, but use a third party gateway to handle the payments using the correct SSL certificate would cover this.

If you did not store anyone's credit card details and you are using a third party api and gateway, doing the transactio on their 'compliant' servers, then I can't seem to work out the logic here. Perhaps I am missing something, but as far as my thinking is, and the relationship I have with my clients who sell online, we don't and have never stored people's credit cards on our infrastructure, but chosen to use third party providers, so why would that affect them?

And I don't understand how it can be assumed that DNN itself should invest in beign 'certified' when it provides the framework for the community to build on.  I could understand however, that someone who needs this as part of them doing business may need to invest in getting this done.

Do you have any more reading on this matter?

Nina


Nina Meiers My Little Website
If it's on DNN, I fix, build, deploy, support,skin, host, design, consult, implement, integrate and done since 2003.
Who am I? Just a city chic, having a crack at organic berry farming.. and creating awesome websites.
 
New Post
5/8/2009 9:42 PM
 

I agree with your take on this, Nina.


pmgerholdt
 
New Post
5/8/2009 9:57 PM
 

As always, Nina's posts (apparently rare these days?) are right on the money. No, DNN does not have to be certified by any means. The store module they're using, maybe (if at all). If it's using a payment gateway, which most stores do, there's no problem. Just don't store credit card info, security codes, etc. If you have to, encrypt them or better yet, download them to a protected, not publicly accessible computer. 

I have had an online storefront since 1995. I'm always amazed at the lengths the credit card companies go to, to "insure" secure transactions (NOT!). PCI DSS is just another measure of vague guidelines and "multifaceted security standards" as they call it, that they use to CTP (cover their posteriors). Basically, PCI DSS is their shield. In case your data gets compromised, they'll flash their PCI DSS guidelines, hit your over the head with them and say it's all your fault.

On the other hand, many years ago (about 10), out of 3 fraudulent transactions that got by my system's security precautions (in 15 years!!!!), I managed to get complete purchaser information from one particular "bozo". I had the IP address and significant personally identifying information, down to a his IP address (easy), his computer's network card MAC address (quite a bit harder) and a reliable, physical address. I immediately contacted the credit card owner's card issuing bank.  Imagine my surprise when they didn't give a s**t. They didn't even want the information I had. They could have easily snagged the crook, but they really, really didn't want to. As a merchant, I am painfully aware that anytime there is a problem with a transaction, they'll simply charge back to your account (i.e., take the money back!) and it's ALWAYS your loss. 

The credit card companies really have no incentive to create an environment for safe and secure transactions. While technically possible to do so, 16 digits, an expiration date plus a 3/4 digit security code really don't cut it anymore for online transactions. PCI DSS  to the rescue? You have got to be kidding!!! It's a lot easier for them to come up with fairly meaningless guidelines than actually implement a simple challenge/response system that could easily verify online transactions and eliminate 99% of the problems in the first place.

I apologize for hijacking this thread to (mostly) vent.

 
New Post
5/9/2009 6:00 AM
 

Nina - thanks for your response, and on  the face of it, I agree with you too. However, I am using (very successfully) ASPDNSF's ML/DNN product, and when I asked them about compliance, they had this to say:

" This was actually required for Level 3 and Level 4 merchants in October of 2008. October of 2009 is when they will stop allowing VISA transactions through the VPNs for all uncertified carts. Until DNN itself decides to be compliant (at this time they are not)...the ML/DNN platform cannot be truly compliant. We maintain our best practices and follow the same guidelines and regulations when developing on the ML/DNN platform that we follow on the ML platform but at this time we will not be submitting the ML/DNN platform for certification unless the DNN platform becomes certified; our certification won't matter if it's installed into a non-certified platform."

This response seems to suggest that no ecomm modules using DNN as the platform can be certified PCI Compliant until DNN itself is (hence my original post). However, I am aware there are two types of compliance:

PCI-DSS requires a Merchant to undergo compliance
PA-DSS  requires an application vendor to undergo compliance

What is not clear to me (as a Merchant) is that my PCI-DSS compliance seems to depend on the compliance of any 3rd Parties involved in the transaction processing - in my case this is the ML/DNN application (and maybe the DNN platform), the hosting environment (PowerDNN ) plus the payment gateway (ProtX).

Am I right in thinking that PCI compliance is dependant on PA compliance?

I do not store credit card information, I use SSL for encryption and PowerDNN do a great job of securing the hosting environment and provide monthly vulnerability scans (which I have passed fully), so I 'feel' compliant, but have a concern over the definition.

 

I'd would be extremely grateful if this thread could get some firm direction for all.

 

 
Previous
 
Next
HomeHomeOur CommunityOur CommunityGeneral Discuss...General Discuss...PCI - DSS: Will DNN be compliant?PCI - DSS: Will DNN be compliant?


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.