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