Page 1 of 1

Moving between Secure and non-secure sessions for logging in

Posted: Thu Apr 20, 2006 7:24 am
by hessodreamy
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?

Re: Moving between Secure and non-secure sessions for loggin

Posted: Thu Apr 20, 2006 7:40 am
by Chris Corbyn
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.

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?
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 ease :) I've seen it done on other sites. Using SSL for the duration of an entire session does have a performance impact yes but 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

Posted: Thu Apr 20, 2006 7:50 am
by hessodreamy
Sorry I don't quite get your last comment:
d11wtq wrote: depending upon the content of the system you may be wise to just stick with that encryption.
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 forum :D

Re: Moving between Secure and non-secure sessions for loggin

Posted: Thu Apr 20, 2006 8:09 am
by Roja
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.
To what scale are you looking to engineer this?

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.
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?
The alternative is to require javascript, and use it to encrypt the login.

Posted: Thu Apr 20, 2006 8:31 am
by hessodreamy
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 :)

Posted: Thu Apr 20, 2006 9:38 am
by Roja
hessodreamy wrote:We get about 15000 hits a day. So you think that the perforance impact would not too bad?
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: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?
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.

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.
hessodreamy wrote:And how would you use Javascript to encrypt the logon?
http://pajhome.org.uk/crypt/md5/
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.
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.

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.
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 :)
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.

Posted: Thu Apr 20, 2006 9:53 am
by hessodreamy
I just meant that if I'd need to implement SSL login to ensure maximum compatability then it seems to me that there's little use in using javascript hashing?

Posted: Thu Apr 20, 2006 10:08 am
by Roja
hessodreamy wrote:I just meant that if I'd need to implement SSL login to ensure maximum compatability then it seems to me that there's little use in using javascript hashing?
That is correct. JS is the alternative for when you aren't using SSL. Using both would be overkill and a waste.