Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Life of a Stripe Charge

petekeen.net

Post reply on HN
Print view View original

21–30 of 37 posts

Re: The Life of a Stripe Charge

#21

Post by patcheudor »

pixl97 wrote: post #15
patcheudor wrote: post #9

Earlier quoted context omitted.

Wow, I just checked their guidance & they absolutely need to reconsider their guidance: "Do I need to be PCI compliant? What do I have to do? Anyone accepting credit card payments must be PCI compliant—but with Stripe, it's easy: Serve your payment page over SSL, i.e., the page's web address should begin with "https", not "http". Use Stripe.js as the only means by which you accept payment information and transmit it…

Just over 'SSL' itself isn't enough, even if it was enough. There are so many broken configurations and weak ciphers that just having a lock on your url bar isn't enough. https://www.ssllabs.com/ssltest/index.html

Yup, and that's just the start of the issues when it comes to trying to side-step PCI compliance through claiming tokenization takes care of it all.

Re: The Life of a Stripe Charge

#22

Post by patcheudor »

superuser2 wrote: post #19
MarkMc wrote: post #17

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?

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.

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.

Re: The Life of a Stripe Charge

#23

Post by MarkMc »

superuser2 wrote: post #19
MarkMc wrote: post #17

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?

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.

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

Re: The Life of a Stripe Charge

#24

Post by MarkMc »

patcheudor wrote: post #22
superuser2 wrote: post #19

Earlier quoted context omitted.

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.

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 de…

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.

Re: The Life of a Stripe Charge

#25

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

Re: The Life of a Stripe Charge

#26

Post by superuser2 »

MarkMc wrote: post #23
superuser2 wrote: post #19

Earlier quoted context omitted.

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.

> 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 identif…

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

Re: The Life of a Stripe Charge

#27

Post by lsh123 »

patcheudor wrote: post #2

"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, th…

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

Re: The Life of a Stripe Charge

#28

Post by 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?

Re: The Life of a Stripe Charge

#29

Post by mmcnickle »

joosters wrote: post #28

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?

From the article:

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

Re: The Life of a Stripe Charge

#30

Post by joosters »

mmcnickle wrote: post #29
joosters wrote: post #28

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?

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

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:

&card[number]=4242+4242+4242+4242&card[cvc]=123" rel="nofollow">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?

Post reply on HN