Page 1 of 1

Security Advice

Posted: Mon May 16, 2005 5:03 pm
by neophyte
I'm working on a user system that uses a simple SESSION cookie to log people in and out. It stores the username and an md5 encrypted password in the $_SESSION variable. Every page accessed checks the username and password against the db to see if the user is logged in. That seems to be fine until I need to switch to a secure server address on the same unshared server. At which point the $_SESSION cookie is lost. I need the user to log back in. I can:

1. prompt them to log back in
2. pass the username and hashed password via get or hidden post vars

I would prefer the user to be automatically logged in by passing the variables.

Obviously prompting a login is the most secure. But which of the two query strings or hidden post variables are more secure? Or is this a dumb way to do it? Is there a way I could make this more secure with out implementing a session table or prompting for user and password again?

Thanks for your advice

Jcart | Fixed title :roll:

Posted: Mon May 16, 2005 5:14 pm
by evilmonkey
It's probably a bad idea to keep the password in the $_SESSION[] superglobal, even if it is encrypted. Also, in each run of the script, you query the database checking whether or not the username/password combination exists. This wastes processor cycles and excution time. I suggest having a login script which asks for a username and a password. Then, create $_SESSION['active_session'] and set it to 1 (or yes or whatever you want). Also, for checking purposes, carry the username in the $_SESSION[] superglobal (if at any time you need to know who's accessing the page. The point is, don't query the database on the run of each script, do something like this:

Code: Select all

<?php
if ($_SEESION['active_session'] !== 1){
    exit ("f00lisH haXX0rZ");
}
else {
    //carry on with the script
}
?>
Just a suggestion.

Posted: Mon May 16, 2005 9:52 pm
by Skara
*barges in*
It's probably a bad idea to keep the password in the $_SESSION[] superglobal, even if it is encrypted.
Does that include md5()'d passwords?

Posted: Tue May 17, 2005 12:23 am
by Burrito
I agree in that it's a waste of processor to check on every page whether or not the user is "valid" by querying the db on every page load. Just set one session var when they log in and use an include with your session info that redirects them to a log in if the $_SESSION['loggedin'] isn't set...

to answer your question though:

what I ended up doing in a similar situation was grabbing the UN and pass on the page before it pushed them to my secure site, then dump that into a hidden form var and reset my session vars on the secure site once they're in by querying the db and reassigning $_SESSION['loggedin']. I think with an md5 or sha1 you should be ok. I don't know of any other solution short of using db sessions that would work for you.

Posted: Tue May 17, 2005 8:19 am
by neophyte
Thanks for the advice. I agree that checking against the db on every page is a waste. I am using hidden fields/and query strings to pass user and password. There doesn't seem to be away around that with out implementing a session table.

Thanks

Posted: Tue May 17, 2005 10:47 am
by AGISB
Switching to the secure server means switching it to another domain. e.g. from
http://www.yourdomain.com to ssl.yourdomain.com. This means the session cookie is lost as ssl. can't read the www. cookie in the default installation.

try

Code: Select all

session_set_cookie_params(0, '/', '.yourdomain.com');
before you use session_start() on every page.

This will solve the cockie problem as long as you stay on the same domainname.

Posted: Tue May 17, 2005 11:06 am
by neophyte
I'm not losing the session cookie at any other time than when I switch from domain.com to secure.domain.com which was expected. I don't think there is a way to prevent that from happening. Can you use: session_set_cookie_params() to access cookies set on domain.com after moving to ssl.domain.com? Thanks for the function tip. I didn't know about that one.

Posted: Tue May 17, 2005 11:10 am
by AGISB
the '.yourdomain.com' (the dot is important) lets you read a cookie on every subdomain like e.g. www. ssl.

There is no way to read the cookie if the domain name changes.

Posted: Tue May 17, 2005 11:53 am
by neophyte
VERY COOL! Thanks so much. That solves the login in issue completely! Suddenly I have no issues... well maybe :roll:

:D 8)

Thanks!

Posted: Tue May 17, 2005 1:58 pm
by neophyte
eh. Doesn't seem to work for secure.domain.com. Bummer. :cry:

Code: Select all

session_set_cookie_params(0, '/', '.mydomain.org');

Posted: Tue May 17, 2005 2:42 pm
by trukfixer
Set 2 cookies at the same time? E.G. setcookie(secure.domain.com); and setcookie(.domain.com) simultaneously on login , then you can maintain state back and forth between ssl and non-ssl?

just a quick suggestion off the top of my head- not really secure to use cookies ..

have you tried grabbing the session_id and passing it as a hidden value (or query string) - might work on some machines .. doesnt on mine, but Ive seen it done elsewhere...

Posted: Tue May 17, 2005 9:24 pm
by Ambush Commander
You've got a single signon problem. Try googling that term.

Posted: Wed May 18, 2005 11:55 am
by AGISB
Did you read the php manual? http://de3.php.net/manual/en/function.s ... params.php ?

The manual has the requirements like the php version.


Here is another post about how it works.
viewtopic.php?t=23988&highlight=session+domain+cookie


If it does not for you it might be a ini issue.