Hacker News Reader

Comment by eurleif | Hacker News Reader

I've only encountered Stripe as a customer, and only once, so it may just be that the merchant (Browserling) was implementing it wrong. But the merchant asked me for my credit card number on its own domain, without SSL. I trusted the site enough to believe it really used Stripe (the only verification was text saying so), and that it was secure, but there was nothing there to prove it to me.

So maybe Stripe is secure, but they might want to work on appearing more trustworthy.

When I've used PayPal as a customer, it asked for my credit card on its own domain, not the merchant's. Doesn't that insulate the merchant from handling credit card details at least as well as Stripe's API does?

View on HN

We actually require that our users use SSL on their payment pages. We describe the requirements (and motivations) in more detail at https://stripe.com/help/ssl.

I don't believe it's possible for a site accepting credit cards on a non-SSL page to be PCI compliant, period, no exceptions. It's trivial to MITM to steal your card info.

The merchant's page is loaded over an insecure connection, but the credit card details are sent to Stripe's servers over a secure connection using an iframe. So it's secure; the customer just can't verify that it is without looking at the source.

Not exactly. Iframes aren't involved (yuck how ugly!). Javascript is used to catch the form's submit, all the data on the form (credit card info) is sent straight to Stripe's server over https (via AJAX) and then their server sends back a response.

Their implementation is both elegant and smart. Even easier than Braintree.

There seems to be an iframe involved: http://i.imgur.com/R4efp.png

If the merchant's page include any Javascript over an insecure connection (for example, jQuery from a CDN) then an attacker can intercept this connection and replace the Javascript by a malicious script that will remove Stripe's iframe and replace it by any other iframe.

So yes, passive network sniffing won't work with Stripe's iframe being loaded over HTTPS, but this does not protect against any type of "active" man in the middle attack.

How does the customer know it's even Stripe's javascript running at all? There's nothing preventing the injection of malicious JS to capture the card number.

Reply on news.ycombinator.com