Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. (For example, if you have four groups working on a compiler, you'll get a 4-pass compiler)
Stripe seems pretty scary. One typo, e.g. forget to return false from the submit handler, and poof your credit card data is sent in the clear to an unsecured server. It would be far better if your credit card was entered in a separate pop-up window hosted on stripe or even better if there was something like Facebook connect for credit card companies so you cc num never is typed into a 3rd party site.
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!
Stripe seems pretty scary. One typo, e.g. forget to return false from the submit handler, and poof your credit card data is sent in the clear to an unsecured server. It would be far better if your credit card was entered in a separate pop-up window hosted on stripe or even better if there was something like Facebook connect for credit card companies so you cc num never is typed into a 3rd party site.
Comment Responses
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)..
Reply To This Comment