This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Hi everyone, I have a question on a particular way to use https that, at first look, seems incorrect. I noticed that some sites ( Paypal.com, americanExpress.com ) do not use the same pattern that everybody else does. That pattern is as follows:
As soon as I am redirected on the page of the site that contains the login form, the browser displays allready an https url. Therefore, when I hit the submit button on the login form, my user name and password is encrypted because both the page I'm on and the page that is being called ( or servlet, whatever ) resides on an https protocol. I always thought that this was the only way to go.
Now, as I said earlier, I noticed that some sites use a different way that mechanism... There way is the same way that I just described except that the page that contains the login form, does not display the https protocol...
In fact, if you type www.paypal.com, you will get the login page but the browser will not display https as the protocol being used. If you look at the source code however, the action of the form is an https page.
So, when I first noticed how Paypal works, I thought that the username and password were not protected while they were sent to the https page. But I installed a sniffer on my pc to see if I would be able to pick up the http package that contains the user name and password and to my surprise, I was not able to snif anything. In fact, when I hit the submit button, I did not pick up any http package at all. I thought that I would at least pick up the http package that contains the username and password who is being sent from an http page to an https page.
So my question is, how does this work? The user information seems protected but I dont undersdtand why because I thought that the page who contains the login form had to be in https.
HTTP or HTTPS is used for the entire request-process-result loop from client to server back to client. If the submit action is an HTTPS URL, the request to the server is encrypted.
It may seem backwards, but don't think of the request to login as part of the page with the form for entering login information. As an analogy, consider tax forms. You go to the post office or library and obtain the the correct tax forms in clear text. Anyone watching you can see the forms you pick up. This is the HTTP request to get the login form.
You then go home and fill out the information in the clear. Again, anyone watching over your shoulder can see how much money you make. This is like you entering your login credentials in your browser (though the password entry box shows ***** instead of your password, just as if you covered up the "gross income" box with your other hand while you filled it in.
Finally, you put your tax forms in an envelope and mail it to the IRS. Someone would have to "break into" your envelope in order to see your information. This is the HTTPS request sending your login/password to the server which would have to be decrypted to be useful.
Browsers are not supposed to cache pages that are the result of an HTTPS request, but I don't know if encrypting the request for the login page itself gives you any added security. Who cares if the login page is cached so long as the data you entered isn't.
Joined: Jan 22, 2005
Thank you for your response, it helps a lot. So there is no advantage nor disadvantage of making the login page secure? Then why do most of the commercial sites secure there login page? Maybe because they want customers to see right away that he is on a secure page and therefore he wont ask the question I asked in my first post?
Thank you for your help!
Joined: Aug 07, 2003
Originally posted by Alexandre Folgueras: So there is no advantage nor disadvantage of making the login page secure?
I think that's correct, but I wouldn't bet anything valuable on it. It could be that if it's not encrypted, a browser could cache it, and said browser might also store the values entered for autocomplete the next time it's displayed. That would be bad, and the browsers I've used have all separated autocomplete from storing logins and passwords.
Then why do most of the commercial sites secure there login page? Maybe because they want customers to see right away that he is on a secure page and therefore he wont ask the question I asked in my first post?
That would be my guess as well.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com