A most important, but also most elusive, aspect of any tool is its influence on the habits of those who train themselves in its use. If the tool is a programming language this influence is, whether we like it or not, an influence on our thinking habits.
The stripe.js file is loaded in via an https server, and presumably anyone implementing this will be smart enough to only host their own server-side calls via https as well.
Anywhere you input your credit card number in a form, you are putting trust the domain actually hosting that form to be following a few basic steps like this -- you can't blame the processing library (stripe, paypal, whatever) for naively insecure (or malicious) implementations by an end-user (read: unknown new e-commerce website). That happens with every payment processing library somewhere in the world at some point, it's up to users to realize the site is a scam (regardless of their supposed use of a credible payment processor).
This actually looks like a pretty foolproof system, it'd be hard to inadvertently share a customer's information using a procedure like this, even when trying to purposely mess up the implementation step in common JS ways. The only things the server-side code could potentially share inadvertently are the customer's email address, and an encrypted identification token. And assuming this is all via https, even those are still encrypted.
The thing is, I don't see anything the example code above to indicate that this is hosting any part of the app (the form or the node.js server app) via https. Am I missing something?
The node.js code doesn't reference any .pem files. Was this left out for the sake of concision? Or if not, how is this an https server?
The entire stripe library is loaded in via https:// and all AJAX calls are done vai https://. in other words, stripe.js is entirely secure. The only risk you have of loosing ANYTHING is the token that stripe returns, which is useless unless you have the secret key (which is secret and stored server-side)..
I am being sponsored by Syntress! They bought me an amazing dedicated server to run catonmat on. If you're looking web services, I highly recommend the Syntress guys!
Education Sponsors
I am being sponsored by A-Writer! If you ever need help with essay writing, look no further than A-Writer! They will help you with your writing in as quickly as 3 hours!
The stripe.js file is loaded in via an https server, and presumably anyone implementing this will be smart enough to only host their own server-side calls via https as well.
Anywhere you input your credit card number in a form, you are putting trust the domain actually hosting that form to be following a few basic steps like this -- you can't blame the processing library (stripe, paypal, whatever) for naively insecure (or malicious) implementations by an end-user (read: unknown new e-commerce website). That happens with every payment processing library somewhere in the world at some point, it's up to users to realize the site is a scam (regardless of their supposed use of a credible payment processor).
This actually looks like a pretty foolproof system, it'd be hard to inadvertently share a customer's information using a procedure like this, even when trying to purposely mess up the implementation step in common JS ways. The only things the server-side code could potentially share inadvertently are the customer's email address, and an encrypted identification token. And assuming this is all via https, even those are still encrypted.
Comment Responses
The thing is, I don't see anything the example code above to indicate that this is hosting any part of the app (the form or the node.js server app) via https. Am I missing something?
The node.js code doesn't reference any .pem files. Was this left out for the sake of concision? Or if not, how is this an https server?
The entire stripe library is loaded in via https:// and all AJAX calls are done vai https://. in other words, stripe.js is entirely secure. The only risk you have of loosing ANYTHING is the token that stripe returns, which is useless unless you have the secret key (which is secret and stored server-side)..
Reply To This Comment