Are PHP sessions secure enough for login on their own?

Question

Possible Duplicate:
What do I need to store in the php session when user logged in?

I want to use php sessions to log users in. Once I verify their identity, I would store their user_id and has_logged_in in a session. To verify that they're logged in, I would check if their user id is set and has_logged_in is true. Occasionally, I would regenerate the session id through session_regenerate_id(true). Is this secure enough on its own or do I have to take further measures to prevent hijacking and other session security vulnerabilities?

You don't need to store `has_logged_in`, just use `$_SESSION = array();` when logging users out. — Daniel Lubarov, Mar 06 '12 at 03:50

score 7 · Accepted Answer · answered Mar 06 '12 at 03:53

Terminology

User: A visitor.
Client: A particular web-capable software installed on a particular machine.

Understanding Sessions

In order to understand how to make your session secure, you must first understand how sessions work.

Let's see this piece of code:

session_start();

As soon as you call that, PHP will look for a cookie called PHPSESSID (by default). If it is not found, it will create one:

PHPSESSID=h8p6eoh3djplmnum2f696e4vq3

If it is found, it takes the value of PHPSESSID and then loads the corresponding session. That value is called a session_id.

That is the only thing the client will know. Whatever you add into the session variable stays on the server, and is never transfered to the client. That variable doesn't change if you change the content of $_SESSION. It always stays the same until you destroy it or it times out. Therefore, it is useless to try to obfuscate the contents of $_SESSION by hashing it or by other means as the client never receives or sends that information.

Then, in the case of a new session, you will set the variables:

$_SESSION['user'] = 'someuser';

The client will never see that information.

The Problem

A security issue may arise when a malicious user steals the session_id of an other user. Without some kind of check, he will then be free to impersonate that user. We need to find a way to uniquely identify the client (not the user).

One strategy (the most effective) involves checking if the IP of the client who started the session is the same as the IP of the person using the session.

if(logging_in()) {
    $_SESSION['user'] = 'someuser';
    $_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];
}

// The Check on subsequent load
if($_SESSION['ip'] != $_SERVER['REMOTE_ADDR']) {
    die('Session MAY have been hijacked');
}

The problem with that strategy is that if a client uses a load-balancer, or (on long duration session) the user has a dynamic IP, it will trigger a false alert.

Another strategy involves checking the user-agent of the client:

if(logging_in()) {
    $_SESSION['user'] = 'someuser';
    $_SESSION['agent'] = $_SERVER['HTTP_USER_AGENT'];
}

// The Check on subsequent load
if($_SESSION['agent'] != $_SERVER['HTTP_USER_AGENT']) {
    die('Session MAY have been hijacked');
}

The downside of that strategy is that if the client upgrades it's browser or installs an addon (some adds to the user-agent), the user-agent string will change and it will trigger a false alert.

Another strategy is to rotate the session_id on each 5 requests. That way, the session_id theoretically doesn't stay long enough to be hijacked.

if(logging_in()) {
    $_SESSION['user'] = 'someuser';
    $_SESSION['count'] = 5;
}

// The Check on subsequent load
if(($_SESSION['count'] -= 1) == 0) {
    session_regenerate_id();
    $_SESSION['count'] = 5;
}

You may combine each of these strategies as you wish, but you will also combine the downsides.

Unfortunately, no solution is fool-proof. If your session_id is compromised, you are pretty much done for. The above strategies are just stop-gap measures.

You could have just linked to your [other answer](http://stackoverflow.com/a/1225668/283366) instead of copy / pasting — Phil, Mar 06 '12 at 04:13
@Phil: I did, in the original question, when I marked it as a duplicate. The user here was looking for an answer, and I provided it also. — Andrew Moore, Mar 06 '12 at 04:16
Thank you! Sorry for asking a duplicate question but this answer was very helpful. — Rain, Mar 06 '12 at 06:22
How is a `session_id` hijacked? I was pretty confident about my login system until I read this. — sooper, Jan 20 '13 at 19:41
@sooper: Either a malicious software installed on the victim's computer which sends all cookie information to a remote server or inspection of unencrypted traffic. — Andrew Moore, Jan 21 '13 at 02:47

score 0 · Answer 2 · answered Mar 06 '12 at 03:49

just my opinion, as long as you dont need to access a database that needs it userid along with a password, its secure enough. If you are going to store that userid to access something you must be aware of SQL Injection vulnerabilities, i think you know these though.

using it just for a condition like the one you mentioned would be secure enough. well thats what i used.

Are PHP sessions secure enough for login on their own?

2 Answers2

Terminology

Understanding Sessions

The Problem