Security Issues

Hi!

I have a few questions about the security of the CS-Cart application. I did not find everything in the documentation. Who can help me with the following questions?
1. User passwords are hashed in the database. By what method are they hashed? Is the method considered secure?
2. if the option "Remove CC info" (CC = Credit Card) is activated for all order statuses, can I assume that no credit card information is stored in the database at any time? Not even for a few seconds?
Looking forwward to your answers!
Best regards
hummer

1. Passwords are hashed using password_hash (https://www.php.net/manual/en/function.password-hash.php)

2. This depends heavily on the payment integration you have selected. One thing to note, is that credit card information is *always* encrypted using the secret key set in your `config.local.php` file.

Thank you, harmsmitsdev!

To the second question:

- Found that $config['crypt_key'] in config.local.php. What is the name of the safety technology behind this? Is it a certain type of encryption?

- Do you know how it is with "Stripe" as payment processor? Sure, the credit card number is transferred to the Stripe API - but is it also stored in the CS Cart database (even if it's only for seconds, because all status have "Remove CC info" enabled)?

Looking forward to your answer.

- for example the key is used in generating security hash to protect forms from CRSF attacks

- for Stripe integration card details are not stored in DB even for seconds

- for Stripe integration card details are not stored in DB even for seconds

Regarding Stripe: is there a possibility to get the user redirected to stripe.com in order to make the credit card entries THERE (on stripe.com) and not on my website? I mean a behavior as we know it from Paypal (redirect to paypal, make the payment, return to shop).

Looking forward to your answer!

Best regards

hummer

Regarding Stripe: is there a possibility to get the user redirected to stripe.com in order to make the credit card entries THERE (on stripe.com) and not on my website? I mean a behavior as we know it from Paypal (redirect to paypal, make the payment, return to shop).

Looking forward to your answer!

Best regards

hummer

Current integration does not allow it

Thank you, harmsmitsdev!

To the second question:

- Found that $config['crypt_key'] in config.local.php. What is the name of the safety technology behind this? Is it a certain type of encryption?

- Do you know how it is with "Stripe" as payment processor? Sure, the credit card number is transferred to the Stripe API - but is it also stored in the CS Cart database (even if it's only for seconds, because all status have "Remove CC info" enabled)?

Looking forward to your answer.

It uses Blowfish for encryption.

Using any payment method that does not use iFrames, 3D Secure or redirect to a secure card site for entry of card information is NOT PCI Compliant. If you ever get a breach or one of your customers complains to Visa (et al) that their card was compromised from being used on your site you are up for a very expensive and long process of redemption.

Hmmm interesting. I was aware that I had to be PCI compliant and having read that cs-cart is PCI compliant I didn't give it another thought after my purchase (until now). Those who have posted before me are obivously across it, but for those joining us on the journey ... PCI is a standardad that must be implented "... for all entities that store, process or transmit cardholder data". It applies to services provided by the biggest credit card providers.

It seems as EZ has suggested above that credit providers can come at you for fraudulant transactions if you take part in any part of the process and you aren't PCI compliance.

cs_cart MVE gotchas?

  1. the standard requires changing of default security credentials, I could find no reference to the "crypt_key" in the cs_cart installation documentation. harmsdev mentions this one above, does this need to changed to be compliant (I think it does by virtue of PCI requirement 2)?
  2. whilst remove credit card info is set for all order statuses out of the box, it does not remove all data, it removes the majority of the credit card number and 3 digit code. The PCI standard (as far as I can find) does not differentiate partial details and complete details. Feels like a loophole a credit providers lawyers could get you on?
  3. Out of the box cs_cart allows vendors to add payment methods, if I allow my vendors to add credit card payment methods,
    1. who's responsible for the PCI compliance for that vendor i.e. who will the credit provider come after if there is a fraud?
    2. if it is the vendor can they ever become compliant (given there is only a single crypt_key for the market place).

Any thoughts on these or other similar gotchas much appreciated!

Out of scope: I now also understand that there is more to PCI compliance than any software can supply out of the box (such as registering, required audits, hardware requirements).

Australia based operator

CS Cart MVE

You can be PCI compliant using payment methods that either process cards at their site and/or utilize iFrame or other technologies whereby the card data from a payment form is tokenized before it gets transmitted to your site. Removing card data AFTER a payment is processed does NOT make you PCI compliant. Capturing things like expiry data and last-4 of card number does NOT jeopardize your compliance but ANY storage (even in memory) on your server of the card data (encrypted or not) makes you non-compliant in cs-cart since there is no reasonable way to decrypt encoded data and re-store it with a new encryption key. The same encrypt/decrypt functionality is used for all encryption, not just cards..

My suggestion is to only use payment methods that conform to the criteria above (no transfer/storage of card data).

Of course, you can ignore it. But if you get a complaint, it can cost you thousands of dollars to become compliant and to undergo ongoing testing and validation. Best to simply not handle the cards and thereby not have PCI become an issue.

My suggestion is to only use payment methods that conform to the criteria above (no transfer/storage of card data).

Hi!

If you have a Multi Vendor Edition and want to use the automatic revenue sharing between the vendors, then in CS Cart (for European users) only Stripe Connect remains?! Which then has the consequence of not being PCI compliant, right?
Best regards
hummer

Hi!

If you have a Multi Vendor Edition and want to use the automatic revenue sharing between the vendors, then in CS Cart (for European users) only Stripe Connect remains?! Which then has the consequence of not being PCI compliant, right?
Best regards
hummer

As I briefly looked at the stripe code, it appears that it is compliant. I.e. it tokenizes that actual card number so what's stored is an encrypted form of the card that can't be decoded by anyone other than stripe (trying to put it in simple terms).

This question would best be answered by the cs-cart development team or the helpdesk.

This question would best be answered by the cs-cart development team or the helpdesk.

I have often wished that someone from the official CS Cart side would also comment in this forum.
Hello CS Cart, can someone here comment on how it is with PCI compliance in general and specifically (Stripe and Stripe Connect)?
Looking forward to your contributions!