Hi!
Hi!
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?
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!
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 regardshummer
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.