4 ms·

I don't understand why Stripe needs to know my customer's credit card number. Wouldn't it improve security if my web page encrypted the credit card number usin

by MarkMc 13y ago

I don't understand why Stripe needs to know my customer's credit card number. Wouldn't it improve security if my web page encrypted the credit card number using Mastercard's public key before sending it to Stripe?

superuser2 13y ago
If services like Stripe accepted already-encrypted credit card numbers, couldn't someone just steal the already-encrypted credit card numbers and run them through Stripe? Also, resting the security of the payment infrastructure on a single keypair (per network) seems a bit risky. You'd probably want a more sophisticated infrastructure which individually identifies players and allows for revocation, ala chip & pin.
- patcheudor 13y ago
  In reality, it doesn't matter what controls you implement in the JS including DOM resident encryption. If your network, your server, or your application is vulnerable a bad guy can simply change the payment script directly or even entirely overwrite the DOM with their code. When it comes to PCI compliance companies are responsible for securing the end to end payment path which includes the security surrounding the delivery of the payment form.
  - MarkMc 13y ago
    Sure, encrypting in Javascript would not affect the security of my server and network. But it would increase security of the system as whole, wouldn't it? That is, an attack on Stripe's servers would be less likely to reveal credit card information.
    - patcheudor 13y ago
      The most probable place of attack is at the merchant where a bad guy would simply remove the Stripe JS code or modify the DOM in a way to replace the credit-card collection form within the merchant same origin. Please reference the PCI DSS. It states that the controls outlined in that document apply to all processing components. A merchant website calling the Stripe JS within the same origin of their domain eg., http://my.ecommercesite.com/payment http://my.ecommercesite.com/payment is a payment component, period. The only way to remove PCI responsibility would be to load the payment page at stripe.com so that the browser URL shows https://stripe.com/.. https://stripe.com/... https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pd...
      - MarkMc 13y ago
        I agree with everything you say. I agree that the most likely point of attack is the merchant's website. I agree encrypting the credit card number in javascript would not remove PCI responsibility from the merchant. But I don't see how that affects the question of whether the merchant should encrypt the credit card number before sending it to Stripe. Are you saying that such a practice would not improve the overall security of the system? Or that there is no need to improve security if the system is already PCI compliant?
        patcheudor 13y ago
        Right, encrypting it beforehand makes no difference whatsoever & the merchant must consider that they have PCI obligations so long as they host the form within the context of their same origin.
- MarkMc 13y ago
  > If services like Stripe accepted already-encrypted credit card numbers, couldn't someone just steal the already-encrypted credit card numbers and run them through Stripe? OK then encrypt the credit card number + merchant ID > Also, resting the security of the payment infrastructure on a single keypair (per network) seems a bit risky. You'd probably want a more sophisticated infrastructure which individually identifies players and allows for revocation, ala chip & pin. Then perhaps Mastercard could have a separate public/private key pair for each merchant. Although even a single key pair for each card network would still be better than the status quo, wouldn't it?
  - superuser2 13y ago
    >OK then encrypt the credit card number + merchant ID That would be significantly better. >Although even a single key pair for each card network would still be better than the status quo, wouldn't it? If it gives people the impression that they no longer need to even try to protect their infrastructure because the card numbers are already encrypted, then yes.

by MarkMc 13y ago

superuser2 13y ago

If services like Stripe accepted already-encrypted credit card numbers, couldn't someone just steal the already-encrypted credit card numbers and run them through Stripe? Also, resting the security of the payment infrastructure on a single keypair (per network) seems a bit risky. You'd probably want a more sophisticated infrastructure which individually identifies players and allows for revocation, ala chip & pin.

patcheudor 13y ago
In reality, it doesn't matter what controls you implement in the JS including DOM resident encryption. If your network, your server, or your application is vulnerable a bad guy can simply change the payment script directly or even entirely overwrite the DOM with their code. When it comes to PCI compliance companies are responsible for securing the end to end payment path which includes the security surrounding the delivery of the payment form.
- MarkMc 13y ago
  Sure, encrypting in Javascript would not affect the security of my server and network. But it would increase security of the system as whole, wouldn't it? That is, an attack on Stripe's servers would be less likely to reveal credit card information.
  - patcheudor 13y ago
    The most probable place of attack is at the merchant where a bad guy would simply remove the Stripe JS code or modify the DOM in a way to replace the credit-card collection form within the merchant same origin. Please reference the PCI DSS. It states that the controls outlined in that document apply to all processing components. A merchant website calling the Stripe JS within the same origin of their domain eg., http://my.ecommercesite.com/payment http://my.ecommercesite.com/payment is a payment component, period. The only way to remove PCI responsibility would be to load the payment page at stripe.com so that the browser URL shows https://stripe.com/.. https://stripe.com/... https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pd...
    - MarkMc 13y ago
      I agree with everything you say. I agree that the most likely point of attack is the merchant's website. I agree encrypting the credit card number in javascript would not remove PCI responsibility from the merchant. But I don't see how that affects the question of whether the merchant should encrypt the credit card number before sending it to Stripe. Are you saying that such a practice would not improve the overall security of the system? Or that there is no need to improve security if the system is already PCI compliant?
      - patcheudor 13y ago
        Right, encrypting it beforehand makes no difference whatsoever & the merchant must consider that they have PCI obligations so long as they host the form within the context of their same origin.
MarkMc 13y ago
> If services like Stripe accepted already-encrypted credit card numbers, couldn't someone just steal the already-encrypted credit card numbers and run them through Stripe? OK then encrypt the credit card number + merchant ID > Also, resting the security of the payment infrastructure on a single keypair (per network) seems a bit risky. You'd probably want a more sophisticated infrastructure which individually identifies players and allows for revocation, ala chip & pin. Then perhaps Mastercard could have a separate public/private key pair for each merchant. Although even a single key pair for each card network would still be better than the status quo, wouldn't it?
- superuser2 13y ago
  >OK then encrypt the credit card number + merchant ID That would be significantly better. >Although even a single key pair for each card network would still be better than the status quo, wouldn't it? If it gives people the impression that they no longer need to even try to protect their infrastructure because the card numbers are already encrypted, then yes.