The Life of a Stripe Charge

https://www.petekeen.net/life-of-a-stripe-charge

by axelbouaziz • 13 years ago

67 35 13 years ago

patcheudor12• 13 years ago

"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_...

zrail2• 13 years ago

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

patcheudor12• 13 years ago

Awesome!

pbreit3• 13 years ago

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

Silhouette3• 13 years ago

If the PCI guys really want small businesses to be careful around tokenization, one might suggest that publishing yet another very long document about technicalities is rather self-defeating.

It's the new generation of payment services like Stripe that are offering out-of-the-box forms and vaults and tokenization and so on. These services are doing well precisely because they manage to make the card payment industry dinosaur and its anachronistic practices and endless bureaucracy at least moderately competitive again for small/medium businesses.

However, if the underlying card schemes and their PCI attack dog start trying to hard to throw their weight around in this sort of area, the industry is going to haemorrhage business to alternative payment methods even faster than it already is.

patcheudor12• 13 years ago

The problem is when companies like Stripe provide misleading or patently false guidance in order to build their business. It's very amazing when people buy-into the idea of completely side-stepping PCI by implementing SSL & some Javascript within their same origin.

lsh123• 13 years ago

+1000

You should also mention SDLC process to make sure that a rogue developer of the merchant app doesn't send credit card numbers to a server somewhere else.

krat0sprakhar• 13 years ago

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?

MarkMc4• 13 years 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?

superuser22• 13 years 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.

patcheudor12• 13 years 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.

MarkMc4• 13 years 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?

hipaulshi• 13 years ago

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.

joosters3• 13 years ago

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?

mmcnickle2• 13 years ago

From the article:

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

joosters3• 13 years ago

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... &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?

The Life of a Stripe Charge

Related Stories