Moving between Secure and non-secure sessions for logging in

Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.

Moderator: General Moderators

Post Reply
hessodreamy
Forum Commoner
Posts: 58
Joined: Wed Apr 20, 2005 8:11 am

Moving between Secure and non-secure sessions for logging in

Post 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?
User avatar
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

Post 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.
hessodreamy
Forum Commoner
Posts: 58
Joined: Wed Apr 20, 2005 8:11 am

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

Post 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
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

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

Post 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.
hessodreamy
Forum Commoner
Posts: 58
Joined: Wed Apr 20, 2005 8:11 am

Post 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 :)
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post 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.
hessodreamy
Forum Commoner
Posts: 58
Joined: Wed Apr 20, 2005 8:11 am

Post 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?
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post 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.
Post Reply