I am looking into Authorize.net’s new “Direct Post Method” for handling credit card transactions. Previously, my company has been using Auth.net’s AIM to process credit cards without leaving our website. This method requires that we have an SSL.
However, this new DPM that Auth.net has says that the client still pays on our website but we don’t need an SSL for security. This seems a bit odd to me but that’s what Auth.net says. You can see the charts here: http://developer.authorize.net/api/compare/.
So, my question is this; if I have a page hosted without an ssl (http://etc…) that posts to an SSL (https:///etc…) is the POSTed information secure?
Thanks for any help.
Technically, the information may be secure in transit (after hitting the submit button). But the person filling out the form can’t possibly know that it will be secure (so why should they trust your site?). After all, if the URL bar doesn’t indicate that it is an HTTPS page, how are they supposed to know that it will POST to an HTTPS site?
I wrote about this once before. Although I was accused of being overly paranoid, I still maintain that I wouldn’t trust a site with my credit card details if the page that I’m submitting from (and to, of course) are both SSL.
Look: The whole point of SSL is to prevent man-in-the-middle attacks (that’s all it does). If your form isn’t protected, then an attacker could modify the form to submit to wherever they want.
Man-in-the-middle attacks allow an attacker to modify or monitor information while in transit across the internet. With the prevalence of insecure wireless networks, BGP poisoning, attacks on DNS and new vulnerabilities being discovered every day, it’s also becoming increasingly easy to perform a man-in-the-middle attack.