Using an HTTPS connection is all well and good, but it is not enough. HTTPS is susceptible to man in the middle attacks [1], and securing the params with a pre-shared secret key is essential.
The extra cost in 'complexity' is really far outweighed by the (warranted) extra security.
ssltrip requires a valid root ca, or an ssl library that doesn't check the signing chain. After using it though, the parameters are unencrypted and so can simply be sniffed.
Are you attempting to reencrypt the parameters with another key? If so then why run that through https?
> Are you attempting to reencrypt the parameters with another key? If so then why run that through https?
I think they are talking about generating a hash from all of the parameters in the request + a secret, pre-shared key. Doing so prevents MITM attacks from changing the parameters.
This article also inspired me to lockdown my own API I designed, its really good advice. The question is only, they wanted to provide a very simple interface, what is the right trade-off security vs. developer UI?
I can't see any point in signing the params - an attacker only cares about the CC info, not some hash value. The only use for a secret key would be to encrypt all the params. But SSL already does that...
I was thinking about this too--what access does that API key give someone? Even if it's just to charge a card, it's a risk since it can be used by bad people to validate stolen credit cards.
Either I put my secret key in the javascript and initiate the request in the browser (thus leaking my secret key), or I accept the inputs onto my server and forward the request to Pin, thus increasing PCI compliance burden because now sensitive data is passing through my server.
I'd like this more if it functioned closer to Braintree's transparent redirect. https://www.braintreepayments.com/developers/api-overview No sensitive data ever touches my servers (customer's POST goes to Braintree, and then they redirect to my server with a query string token that I use to validate the tx with Braintree).
It looks like they provide pin.js so that your server never has to accept the credit card details, but rather a single-use token (much like Stripe, I believe).
Oh, that's cool, thanks for the docs link. I like the way the API hijacks the form submit and replaces the card with the token. I'm still a but curious as to what a nefarious user could do with your "publishable API key," but this is much better than I had initially thought.
> I'm still a but curious as to what a nefarious user could do with your "publishable API key,"
I suspect very little if they don't also have your 'secret' API key. I guess they could request a single-use token for a card, but I don't think they could then do anything with it.
