HTTPS for credit card transactions

[mufka]

A merchant that I was planning on purchasing something from accepts credit cards over the internet. I was puzzled that the form for submitting the credit card info was not on a https page (and no lock sign in the browser). Is there another way that they could be securing the connection?

 

[sleipnir214]

Although it provides the user a more comfortable experience to make secure the entire interaction with "pay for stuff" parts of the site, it does not matter whether the credit-card entry form comes to your browser via HTTPS. The part that matters is when you submit the data -- that must be secure.

Check the source HTML of the page you've filled out. Does the "action" attribute of the <form> tag include a reference beginning with "

https://"?

If so, the data will be transmitted securely.



Want to ask the best questions? Read Eric S. Raymond's essay "How To Ask Questions The Smart Way". TANSTAAFL!

 

[mufka]

The form action is to a relative path with no https.

 

[sleipnir214]

Then unless there is some kind of alternate encrypted route, say AJAX or Java via HTTPS, the page will transmit your CC information without encryption.

I would nearly certainly think twice or three times before doing business with that vendor.



Want to ask the best questions? Read Eric S. Raymond's essay "How To Ask Questions The Smart Way". TANSTAAFL!

 

[mufka]

I was under the impression that if the form that took the info wasn't https, the data you submit got sent plaintext from your browser to the action script. Am I wrong?

 

[gb0mb]

I use to work for a large bank. Their websites login page was sent to you as a non encrypted page. Your response was sent out encrypted though. There was such a large volume of tech calls involving that that they finally just made the login in page encrypted also not just the response.

Gb0mb

........99.9% User Error........
Ubuntu -- African for I can't install Gentoo

 

[sleipnir214]

I was under the impression that if the form that took the info wasn't https, the data you submit got sent plaintext from your browser to the action script. Am I wrong?

The method (HTTP or HTTPS) by which your browser fetches the form from the server has necessarily nothing whatsoever to do with the method it uses to transmit the form data back to the server. Keep in mind that HTTP (and HTTPS) is a stateless protocol, and a user's seemingly long multistep interaction with the website is really a series of unrelated communications between the browser and the server.

And I said "has necessarily nothing" because there are some things your browser will carry over from one interaction to the server to the next. One is, of course, explicit state management by the use of cookies, which were invented by Netscape to allow a set of unrelated server/browser interactions to seem to a user to be a single multistep communication.

The other is the state management implicit in browsers' assumptions about site authors' use relative links in web pages. If a browser fetches a form via HTTPS and the "action" attribute of the form tag reads only as a site-relative path to the receiving script, your browser will likely assume the form's data should be returned by HTTPS. I've never seen anything in the HTML or HTTP specs that require this, though.

But if you access a page via only HTTP that contains a form with an "action" attribute beginning "

https://",

then it doesn't matter how the form got to your computer: when you submit the form the data is going back encrypted.



Want to ask the best questions? Read Eric S. Raymond's essay "How To Ask Questions The Smart Way". TANSTAAFL!