
The Life of a Stripe Charge - axelbouaziz
https://www.petekeen.net/life-of-a-stripe-charge
======
patcheudor
"Because your server-side process never knows the real card information, it
doesn't fall into PCI compliance scope."

WRONG! The payment code is delivered by a response from the server-side & as
such it is in scope for at least PCI section six. As an example, if the
JavaScript code or reference comes via an HTTP & not HTTPS request it can be
tampered with on the wire & the code replaced with code from the attacker,
thus getting in the middle of the transaction. If there's an SQLi or
persistent type-2 XSS flaw on the server side an attacker could similarly
modify the code there. People need to stop believing that tokenization does
anything more than remove the need to protect credit-cards in memory on the
server side & pay attention to their security. Since the concept of
tokenization hit the scene I'm seeing worse security around card transactions
than I ever have before in my reviews. Worse, people convinced that
tokenization entirely clears them from PCI responsibility tend to be
argumentative & resistant to what I believe to be common sense guidance.
Luckily the PCI council has been made aware of these issues and provided some
clarification about tokenization:

[https://www.pcisecuritystandards.org/documents/Tokenization_...](https://www.pcisecuritystandards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf)

~~~
zrail
Thank you for the link. That sentence is wrong, I'll fix it to say something
along the lines of "your PCI compliance scope is reduced to the things Stripe
requires you to do on their security guidelines[1]"

(edit: For what it's worth my book does not make the same mistake, and in fact
has a whole chapter dedicated to PCI and HTTPS implementation.)

[1]: [https://support.stripe.com/questions/do-i-need-to-be-pci-
com...](https://support.stripe.com/questions/do-i-need-to-be-pci-compliant-
what-do-i-have-to-do)

~~~
pbreit
So do Stripe merchants have to fill out and/or file any PCI DSS compliance
materials?

~~~
zrail
According to Stripe themselves, no. Honestly most of PCI is common-sense stuff
that you should be doing anyway (firewalls, restricting access, etc) but the
compliance audits are strictly optional with Stripe as long as you're serving
over HTTPS and are using their tokenizing javascript.

~~~
patcheudor
Then Stripe might want to reconsider their guidance in light of the PCI
guidance on tokenization. Reference:

"2.4.2 Merchant Responsibilities"

[https://www.pcisecuritystandards.org/documents/Tokenization_...](https://www.pcisecuritystandards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf)

The only way out of being responsible for PCI compliance would be to offload
the entire transaction to the payment provider. This means sending the
customer entirely off domain of the merchant (iFrames don't get you there) so
that the entire same origin of the transaction is within the complete control
of the payment provider. The second the merchant loads an iFrame or any
JavaScript within their same origin, they are accountable, period.

~~~
pbreit
After reading the doc and paying close attention to that section, it's not
clear to me what the Stripe problem is. I didn't see anywhere that the Stripe
approach would not comply.

~~~
patcheudor
Because the merchant is still responsible for delivering the payment form
within their same origin in a secure manner which means that the merchant must
secure their hosts so that the delivery of that payment form cannot be
tampered.

------
joosters
Is it really a good idea to be making HTTP requests with the card number and
CVC in the URL?

I get that it's over HTTPS, so the whole thing is encrypted, but won't the URL
still be saved in my browser history, which will end up on disk and be
available to anyone who gets on to my computer?

If the request was a POST method instead, you'd avoid these possible
weaknesses. Or am I missing something?

~~~
mmcnickle
From the article:

> Stripe POSTs at a /tokens API endpoint over https, which means everything is
> encrypted including the query params

~~~
joosters
It's still a little unclear: It says that it is a POST, but the URL in the box
above contains the card details. Further, the bit of text you quote goes on to
say:

> ...including the query params. These params include the card number,
> expiration date, and CVC

The URL they give as an example is:

[https://api.stripe.com/v1/tokens?email=foo%40example.com&pay...](https://api.stripe.com/v1/tokens?email=foo%40example.com&payment_user_agent=Stripe+Checkout&amount=0&iovation_blackbox=a_very_large_string>&card\[number\]=4242+4242+4242+4242&card\[cvc\]=123)
&card[exp_month]=4&card[exp_year]=2014&card[name]=foo%40example.com&key=pk_test_6pRNASCoBOKtIshFeQd4XMUh&callback=sjsonp1390180955159&_method=POST

So are these params in the URL, or not?

~~~
mmcnickle
No, the output in the box is from the web console, which uses the GET-style
URL as a concise way of showing POST requests.

~~~
joosters
Ah, I see. Thanks for the clarification!

------
krat0sprakhar
We're an ecommerce company who have been dealing with the baggage of "1-click
buy" that we implemented a year back. To persist the cards we had to build our
own infrastructure thereby increasing our PCI exposure. The yearly audits,
honestly, are costing us a fortune. I need to make a business case around
getting rid of the card related infrastructure and using some third party that
provides tokenization-as-a-service. Are there any vendors out there who do
that?

After doing this,will my PCI exposure reduce significantly? As long as my
customers are entering their CC details over the vendor's secure page and I'm
making encrypted API calls to their service on HTTPS pages (like Stripe) do I
still need to get PCI Certified?

------
hipaulshi
I never used Stripe before, but seeing the tokenization method without
revealing information to third-party backend to stay compliant just makes me
cry. Smart solution.

EDIT: Agree with the top commenter. 3rd party website can always be
compromised. Tokenization only takes care one side of the story.

------
MarkMc
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
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.

~~~
MarkMc
> 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
>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.

