Protx VSP Direct 3.x

[conor]

Hi,

Is there any more information I can provide to help you troubleshoot my problem?

The new versions of the module (3.4.x) disables themselves if a problem with the configuration is found.

Are you getting any configuration error messages in the admin?

If not, please get in contact privately via our website with your shop's admin details and FTP details so I can debug your site.

All the best...

Conor
Ceon

[pfm102]

I'm not getting any configuration errors in the admin (that I can see, anyhow). I'm working on setting up a test-instance of the store for you to examine; the one I was working within is on my local machine - it's probably easier to do that than punch holes in my firewall for you to get in to my dev machine.

I'll let you know when that's ready via your support page.

[Grumbledook]

Hi,

I am currently doing some homework on setting up an online store and was looking at using zencart and protx.

However I am slighty concerned with the whole PCI security compliance stuff and the DPA.

When it comes to hosting do I need to host on a UK server to comply with the data protection act, or can I use a us based server which would be cheaper?

Is using this module with protx and zen cart on a compliant webhost, fully PCI compliant? I havn't seen this anywhere and if it is could you put it on your website?

Any further details or explanation you could provide to clear up the whole PCI compliance issue would be great too.

[conor]

Hi,

PCI compliance seems to be mostly about protecting your network from outsiders and your own employees, so 99.9% of the effort to be put into complying would appear to be to do with how you manage your business.

Finding out what actual technical requirements are necessary for compliance doesn't seem to be a very easy thing to do. I personally don't know exactly what is required and can't find any easy to read information anywhere which enlightens me.

However, I would guess that, from a technical point of view, card information must be kept secure at all times.

Protx Direct doesn't result in any card information being stored with the vendor, except on a temporary, transitional basis. The only time details are stored is when the customer moves from the payment page to the confirmation page (and possibly back again). The details are then stored the session. If the customer leaves the checkout process, the details are removed from the session (when/if they come back to the checkout or go to the shopping cart page).

While the details are stored in the session they are encrypted using a password entered in the module's configuration. This encryption cannot be broken without that password.

For those on a shared server, as long as no-one can access your database to get this password, all data is 100% secure. For those with their own server, as long as no-one can access your server to get access to the database - and therefore the encryption password - all data is 100% secure.

When the card details are sent to Protx it is over a secure connection and the card details are not stored by the module.

I don't know if that's cleared anything up for you but it's the best way I think the module can work in terms of security while still offering the customer a pleasant checkout experience. The only other alternative would be to hack the payment pages to temporarily record card details within any forms and to accept that the card details will have to be re-entered from scratch any time a user uses a HTML link.

The card details are stored (encrypted) in the session temporarily for the sole purpose of letting customers move about the checkout (to make shipping changes, shopping basket changes etc.) without having to re-enter their payment details every time they do so (as all other Zen Cart modules that take card payments seem to require).

All the best...

Conor
Ceon

[Grumbledook]

Yer that clears it up a bit,

Shame the PCI compliance stuff isn't written somewhere as an idiots guide, especially given the repercussions to your business if you are found to be non compliant.

Or has anyone had to deal with this in any case. From the looks of it, assuming your webhost is compliant, and protx are certified, I would have to assume that it all is fine. But you know what they say about assumption ;]

[blackroom]

Hi Grumbledook,

I was looking into this as well. I don't know if this page from the Protx site is of any help - http://www.protx.co.uk/aboutus/accred_pci_does.asp.

I spoke to my hosting company about this and they said it was the first enquiry about PCI they'd had in over a year!

Cheers

[CJPinder]

Hi,

Protx Direct doesn't result in any card information being stored with the vendor, except on a temporary, transitional basis. The only time details are stored is when the customer moves from the payment page to the confirmation page (and possibly back again). The details are then stored the session. If the customer leaves the checkout process, the details are removed from the session (when/if they come back to the checkout or go to the shopping cart page).

I currently use ProtX Form and have been looking into moving to Protx Direct. The statement you made above troubles me a bit though. It sounds as if the full card number, dates, card holder name etc are stored for a short time in the session and therefore in the database (or even on the filesystem). The fact that the details are encrypted doesn't make much difference, especially if the decryption password is also held in the database. Is the card validation code also stored in the session?

Is there an easy way to turn this off so that the card details are not stored in the session and never touch the database?

Many thanks,
Christian.

[conor]

Hi Christian,

Is there an easy way to turn this off so that the card details are not stored in the session and never touch the database?

If someone has access to your database and/or your files you don't have any security whatsoever so anything you do is moot... what is stop this person from simply copying all card details POSTed to your server to an external site? Nothing! :)

However, if you want to disable the temporary storage of card details in the session, just a single line in the code needs to be commented out. Customers will then have to re-enter their card details every time they want to make a change in the checkout process (change addresses, cart quanities etc.).

There is no "switch" for this in the config as I believe that if someone has access to your database/files all data should be assumed to be compromised already and the site should be shut down until that is sorted.

Hope that's of help to you! :)

All the best...

Conor
Ceon

[CJPinder]

If someone has access to your database and/or your files you don't have any security whatsoever so anything you do is moot... what is stop this person from simply copying all card details POSTed to your server to an external site? Nothing! :)

Agreed, but when dealing with PCI compliance network and server security is a separate issue that also has to be dealt with.

What I'm trying to get at is that if the card details are stored in the database then they have to be stored securely. Encrypting the details provides security as long as the encryption method is secure. If you are also storing the decryption key in the database then your encryption is not secure and the data may as well not be encrypted.

The other issue is the card verification number which must never be stored. Can you confirm that this isn't stored in the session at anytime?

However, if you want to disable the temporary storage of card details in the session, just a single line in the code needs to be commented out. Customers will then have to re-enter their card details every time they want to make a change in the checkout process (change addresses, cart quanities etc.).

I think for PCI compliance this would have to be done. If you are storing the encrypted card details alongside the decryption key then you are not storing the data securely and the method is not PCI compliant.

Regards,
Christian.

[conor]

Hi,

Agreed, but when dealing with PCI compliance network and server security is a separate issue that also has to be dealt with.

What I'm trying to get at is that if the card details are stored in the database then they have to be stored securely. Encrypting the details provides security as long as the encryption method is secure. If you are also storing the decryption key in the database then your encryption is not secure and the data may as well not be encrypted.

The primary reason behind adding the encryption of stored details to the module is so that the session details stored in a file are protected. The encryption is not there to protect against a database being compromised, that cannot be done. Many people use shared servers which store session information in temporary files in a shared location (e.g. /tmp). The module's encryption is aimed at protecting that information from other users of the server who are idly browsing the contents of the temp folder.

The other issue is the card verification number which must never be stored. Can you confirm that this isn't stored in the session at anytime?

Nope, it is.

I think for PCI compliance this would have to be done. If you are storing the encrypted card details alongside the decryption key then you are not storing the data securely and the method is not PCI compliant.

I've never claimed PCI compliance for the module, it's not an issue that concerns me much. I want things to be as secure as possible on a practical level while still providing a good customer service. Being PCI compliant with Zen Cart means that you have to degrade the customer's experience. It also means you cannot use the software on a shared server, you must run a dedicated/co-located server. Most Zen Cart users use shared servers so most can never be PCI compliant regardless of what way the module works. I think it's better for the module therefore to be as secure as practically possible while maximising the customer's experience.

If you run your own server and want to prevent the module storing the card number, expiry date and CVV code temporarily in the session I can tell you what changes to make in the code, they are very simple. However, this isn't an issue of any real practical importance to most Zen Cart users so the module won't be rewritten to be compliant by default. In an ideal world that would be possible but, well... ;-)

All the best...

Conor
Ceon