A session begins when a visiting client somehow identifies itself to the web server. The web server assigns the client a unique session id, which the client uses to re-identify itself as it moves from page to page on the website. Most of the time, these unique ids are stored in session cookies that expire after the client hasn't interacted with the server for some amount of time. The amount of time varies depending on the web application. For example, an online investment site might have very short sessions, so that if a user leaves her computer without logging out, another user who sits down at the same computer several minutes later cannot continue with the first user's session.
Configuring SessionsIn PHP, session management is configured in the php.ini file. To have a user's session start as soon as the user visits the website, the
session.auto_startflag must be set to
The session length is also set in the php.ini file with the
session.gc_maxlifetimevariable. The default value is 1440 seconds (24 minutes).
Session FunctionsThe following table shows the most common session functions.
|Starts new session if one does not exist. Continues current session if one exists.|
|Unsets all session variables.|
Securing PHP User Authentication, Login, and Sessions
Many, if not all, of you have had to deal with creating a secure site login at some point in time. Although there are numerous articles written on the subject it is painstakingly difficult to find useful information from a single source. For this reason I will be discussing various techniques I have used or come across in the past for increasing session security to hinder both session hijacking and brute force password cracking using Rainbow tables or online tools such as GData. I use the word hinder due to the fact no foolproof methods exist for preventing session hijacking or brute force cracking, merely increasing degrees of difficulty. Choose a method wisely based on your site’s current or anticipated traffic, security concerns, and intended site usage. The following examples have been coded using PHP and MySQL. I more than willingly accept comments, suggestions, critiques, and code samples from readers like you as they benefit the community on the whole.
Update: Security Concerns with Hashing AlgorithmsThere are some inherent security considerations to take into account when using very fast hashing algorithms such as SHA or MD5. Modern day, multi-processor computers and GPUs can quickly brute-force passwords that aren’t encrypted with a very slow, secure algorithm. For these reasons, it is recommended you do not use these and instead use bcrypt encryption or sha-256/512 with key stretching. In the near future there will be a post containing this updated method for secure authentication.
Session Best Practices
Use SSL when authenticating users or performing sensitive operations.
One of the comments to the SO answer points out that you have to use HTTPS for every page on the site, or a hacker can easily steal the session ID the first time a non-HTTPS request is made. Does anyone have any thoughts on this?
Regenerate the session id whenever the security level changes (such as logging in). You can even regenerate the session id every request if you wish.
What's the best way to regenerate the session ID? Actual code would be helpful for this. Thanks.
Have sessions time out
How do you make a session time out?
Don't use register globals
What is the problem with using registered globals? I don't get the problem with this at all.
Store authentication details on the server. That is, don't send details such as username in the cookie.
This point is pretty straightforward and obvious.
Check the $_SERVER['HTTP_USER_AGENT']. This adds a small barrier to session hijacking. You can also check the IP address. But this causes problems for users that have changing IP address due to load balancing on multiple internet connections etc (which is the case in our environment here).
A lot of the comments to this answer seem to be related to checking the user agent string. Maybe it's best to just avoid this check. Any thoughts?
Lock down access to the sessions on the file system or use custom session handling
I don't understand this point at all. How do you lock down the session on the file system. Also, how would you go about creating a custom session? Would it just be an array of data stored in the DB?
For sensitive operations consider requiring logged in users to provide their authenication details again
This is a good point, but I think it's important to consider the balance necessary for protecting the user without annoying them too much.
- What is a session?
- How do I use a Session?
- How do sessions work?
- How do I change the value of a session variable?
- Can I destroy a session variable?
- What should I do to destroy a whole session?
- Can I store an array in a session?
- Can I store an object in a session?
- Can I store an file pointer in a session?
- Can I store a function in a session?
- Can I store an image in a session?
- How are sessions stored?
- Storing sessions with SQLite
- When do sessions expire?
- How can I send headers then start a session?
- How can I check if a session is started?
- How can I check if a session uses a cookie or query string
- Session Configuration with php.ini
- Session security