Given that a log in page must be secure, and browsing over https decreases performance, and just looking at some of the big sites out there, it seems that the best way to handle a log in (if browsing is to be continued) is to secure the log in page and then direct back to non-secure when you're done.
However you then get the "It would be possible for others to view information you send" pop-up in IE default settings which would probably be off-putting for the non-technically minded out there.
Is this inevitable? (I could just put a message on the site to say what will happen) or is there anyother way to handle the log on?
Moving between Secure and non-secure sessions for logging in
Moderator: General Moderators
-
hessodreamy
- Forum Commoner
- Posts: 58
- Joined: Wed Apr 20, 2005 8:11 am
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
Re: Moving between Secure and non-secure sessions for loggin
The browser is handling that for security reasons just like you used SSL for security reasons. You can't change that behaviour remotely. If it's something that bothers you then yes, putting notices on your page will put the client at easehessodreamy wrote:Given that a log in page must be secure, and browsing over https decreases performance, and just looking at some of the big sites out there, it seems that the best way to handle a log in (if browsing is to be continued) is to secure the log in page and then direct back to non-secure when you're done.
However you then get the "It would be possible for others to view information you send" pop-up in IE default settings which would probably be off-putting for the non-technically minded out there.
Is this inevitable? (I could just put a message on the site to say what will happen) or is there anyother way to handle the log on?
-
hessodreamy
- Forum Commoner
- Posts: 58
- Joined: Wed Apr 20, 2005 8:11 am
Re: Moving between Secure and non-secure sessions for loggin
Sorry I don't quite get your last comment:

And, yeah, i perfectly willing to work with the user and browser rather than against them. If I wanted to disregard the user's security and usability experience, I'd go to the Javascript forumd11wtq wrote: depending upon the content of the system you may be wise to just stick with that encryption.
Re: Moving between Secure and non-secure sessions for loggin
To what scale are you looking to engineer this?hessodreamy wrote:Given that a log in page must be secure, and browsing over https decreases performance, and just looking at some of the big sites out there, it seems that the best way to handle a log in (if browsing is to be continued) is to secure the log in page and then direct back to non-secure when you're done.
I ask because you mention the performance impact of https, when its really quite minor until you get to very high utilization.. Sites with millions of hits a day can cope with https processing if designed correctly.
The alternative is to require javascript, and use it to encrypt the login.hessodreamy wrote:However you then get the "It would be possible for others to view information you send" pop-up in IE default settings which would probably be off-putting for the non-technically minded out there.
Is this inevitable? (I could just put a message on the site to say what will happen) or is there anyother way to handle the log on?
-
hessodreamy
- Forum Commoner
- Posts: 58
- Joined: Wed Apr 20, 2005 8:11 am
We get about 15000 hits a day. So you think that the perforance impact would not too bad? And do you mean sites should be designed properly in general or with specific reference to https? in which case what considerations should I make?
And how would you use Javascript to encrypt the logon? Do a js call with the details which authenticates the details and updates the session server-side? If the call is secure you'd then get a "Mixed content" warning, would you not? I'm basically trying to avoid giving the user any kind of security alert at all. Besides, I try not to use javascript for anything critical such as login. I don't want to force the user to change any settings or exclude people with the wrong settings. I'm appalled at some sites out there who rely so fundamentally on javascript, especially with not a noscript tag in sight. But that's a different issue entirely
And how would you use Javascript to encrypt the logon? Do a js call with the details which authenticates the details and updates the session server-side? If the call is secure you'd then get a "Mixed content" warning, would you not? I'm basically trying to avoid giving the user any kind of security alert at all. Besides, I try not to use javascript for anything critical such as login. I don't want to force the user to change any settings or exclude people with the wrong settings. I'm appalled at some sites out there who rely so fundamentally on javascript, especially with not a noscript tag in sight. But that's a different issue entirely
Correct. But as with all issues relating to performance, you should measure your specific environment to determine if SSL itself is adding the performance hit, or something else in the page. (This presumes you've found a performance issue at all).hessodreamy wrote:We get about 15000 hits a day. So you think that the perforance impact would not too bad?
Using SSL means you need a fast processor, or ideally, multiple fast processors. Having a crypto accelerator is also a possibility, but I'd just go with a faster processor.hessodreamy wrote:And do you mean sites should be designed properly in general or with specific reference to https? in which case what considerations should I make?
You also want to isolate the webserver from the db server, to ensure that the webserver and ssl connection can focus its power on the connection itself. Then use some aggressive optimizations in Apache configs, and possibly in your db configs. You could even setup a round-robin web cluster if you want to get extremely aggressive.
http://pajhome.org.uk/crypt/md5/hessodreamy wrote:And how would you use Javascript to encrypt the logon?
At the login, you have a form with two (visible) fields: username and password. The password field on submit triggers js that takes the password entry, runs it thru a hash (sha256, sha1, md5), storing it in a hidden form field (hash_pw). the password field is cleared.hessodreamy wrote:Do a js call with the details which authenticates the details and updates the session server-side? If the call is secure you'd then get a "Mixed content" warning, would you not? I'm basically trying to avoid giving the user any kind of security alert at all.
That way no clear text password is sent (that field is cleared), the hashed password is sent, and the browser doesn't store it.
You do not get a mixed content warning at all - that only happens when you have both https and http elements on the same page.
If you want a secure login, you have two, and only two, choices: SSL, or javascript hashing for passwords. Offering a secure login isn't excluding people with the wrong settings - its offering additional functionality that isn't available without it.hessodreamy wrote:Besides, I try not to use javascript for anything critical such as login. I don't want to force the user to change any settings or exclude people with the wrong settings. I'm appalled at some sites out there who rely so fundamentally on javascript, especially with not a noscript tag in sight. But that's a different issue entirely
-
hessodreamy
- Forum Commoner
- Posts: 58
- Joined: Wed Apr 20, 2005 8:11 am