Jump to content

  • You cannot start a new topic
  • You cannot reply to this topic

Security Issues Rate Topic   - - - - -

 
  • hummer
  • Advanced Member
  • Members
  • Join Date: 23-Jul 20
  • 86 posts

Posted 06 October 2021 - 08:59 AM #1

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


 
  • harmsmitsdev
  • Senior Member
  • Members
  • Join Date: 22-Feb 20
  • 206 posts

Posted 06 October 2021 - 11:19 AM #2

1. Passwords are hashed using password_hash (https://www.php.net/...ssword-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.


Best Brands Support - We empower your business!

info@bestbrands.eu


 
  • hummer
  • Advanced Member
  • Members
  • Join Date: 23-Jul 20
  • 86 posts

Posted 06 October 2021 - 11:33 AM #3

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.



 
  • eComLabs
  • CS-Cart Expert
  • Authorized Reseller
  • Join Date: 27-Jan 14
  • 22247 posts

Posted 06 October 2021 - 02:29 PM #4

- 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


GET A FREE QUOTE | CS-Cart Add-ons | CS-Cart Licenses | CS-Cart Development | CS-Cart Design | Server Configuration | UniTheme and YOUPI
CS-Cart                USD 1210     Multi-Vendor              USD 1250    Multi-Vendor PLUS           USD 3100 (2775)
CS-Cart Ultimate  USD 4025     CS-Cart + YOUPI      USD 1459      Multi-Vendor Ultimate       USD 7500 (6000)


 
  • hummer
  • Advanced Member
  • Members
  • Join Date: 23-Jul 20
  • 86 posts

Posted 07 October 2021 - 11:36 AM #5

- 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



 
  • eComLabs
  • CS-Cart Expert
  • Authorized Reseller
  • Join Date: 27-Jan 14
  • 22247 posts

Posted 07 October 2021 - 02:06 PM #6

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


GET A FREE QUOTE | CS-Cart Add-ons | CS-Cart Licenses | CS-Cart Development | CS-Cart Design | Server Configuration | UniTheme and YOUPI
CS-Cart                USD 1210     Multi-Vendor              USD 1250    Multi-Vendor PLUS           USD 3100 (2775)
CS-Cart Ultimate  USD 4025     CS-Cart + YOUPI      USD 1459      Multi-Vendor Ultimate       USD 7500 (6000)


 
  • tbirnseth
  • CS Cart Expert
  • Authorized Reseller
  • Join Date: 08-Nov 08
  • 12107 posts

Posted 07 October 2021 - 09:03 PM #7

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.


EZ Merchant Solutions: Custom (USA based) B2B Development, Consulting, Development and Special Projects (get a quote here).
Commercial addons, payment methods and modifications to meet your business and operations needs.


 

Posted 12 October 2021 - 01:49 AM #8

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 



 
  • tbirnseth
  • CS Cart Expert
  • Authorized Reseller
  • Join Date: 08-Nov 08
  • 12107 posts

Posted 12 October 2021 - 09:18 PM #9

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.


EZ Merchant Solutions: Custom (USA based) B2B Development, Consulting, Development and Special Projects (get a quote here).
Commercial addons, payment methods and modifications to meet your business and operations needs.


 
  • hummer
  • Advanced Member
  • Members
  • Join Date: 23-Jul 20
  • 86 posts

Posted 14 October 2021 - 06:14 AM #10

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


 
  • tbirnseth
  • CS Cart Expert
  • Authorized Reseller
  • Join Date: 08-Nov 08
  • 12107 posts

Posted 14 October 2021 - 09:21 PM #11

 

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.


EZ Merchant Solutions: Custom (USA based) B2B Development, Consulting, Development and Special Projects (get a quote here).
Commercial addons, payment methods and modifications to meet your business and operations needs.