Storing random token in session and cookie?

s0me0ne

When someone logins sucessfully I regenerate a new session and delete the old one, and add some variables to the session, but I also add a random token.

The random token for the session and cookie must match each other, because the check_logged_in() will test both of them, along with filtering and checking the other variables

//random token
$token = md5(uniqid(rand(), true));
$_SESSION['token'] = $token;
setcookie('token', $token, 0, '/', '');

I was wondering if this would be good for security? Or could someone just make the cookie up? I wouldnt think so because they would have to change the one for the session. The more I think about it the more I get confused 😕

Weedpacket

What does this add that isn't already provided by the session ID itself (which is already a random token)? Or do you mean that this random token persists from one session to the next?

NogDog

Weedpacket;10950641 wrote:
What does this add that isn't already provided by the session ID itself (which is already a random token)? Or do you mean that this random token persists from one session to the next?

I was thinking along similar lines as Weedpacket (should I be scared?). If it is that you are regenerating the token on each request, you could get essentially the same effect with [man]session_regenerate_id/man.

laserlight

NogDog wrote:
I was thinking along similar lines as Weedpacket (should I be scared?).

That's okay, I thought the same thing too 🙂

If you are trying to prevent concurrent logins then such an extra token might make sense: you store the token in the database and the session (but not in a cookie) on login, then compare when convenient. On the other hand, such a token does not have to be random, e.g., it could be the login count.

s0me0ne

This random token is generated when they first login sucessfully (I do a regenerate session id, before its set, so when they login they get a new session) and the token stays with them until they logout. The token in the session has to match what is in the cookie. There are some other things I check in the session, ipaddress (only for the admin, not for the members frontend), useragent, and 2 other fields I wont say (dont worry its not the password).

I had thought about storing the token in the database temporarily while they are logged in, but my code is pretty long right now and didnt want to complicate it too much. Although I'm not sure if it would better to store the token or just store the session id in the databases. But I'm not sure how easy it is for someone to modify a session, from what I read they can only modify the session ID and its unlikely they could get another session to match that random token.

laserlight

s0me0ne wrote:
But I'm not sure how easy it is for someone to modify a session, from what I read they can only modify the session ID and its unlikely they could get another session to match that random token.

They cannot modify session data beyond what you allow through your script, but they can try to guess or otherwise obtain the session id (including session fixation: they trick a user into using a session id that they know). If they succeed, the game is over for the compromised account (although such measures as requiring the current password be entered for a password change helps).

Your random token effectively functions as another session id. But if you are already using cookie-only-based sessions, it may not help much: a user who allows an attacker to obtain the cookie containing his/her session id could very well allow the same attacker to obtain the cookie containing the corresponding random token.

Weedpacket

laserlight wrote:
But if you are already using cookie-only-based sessions, it may not help much: a user who allows an attacker to obtain the cookie containing his/her session id could very well allow the same attacker to obtain the cookie containing the corresponding random token.

Alternatively, while passing the session ID in the URL or via a hidden form field would separate the separate the SID from the cookie, it does so only at the weakening of the SID's own security - and still relies on cookies, the very thing that passing the SID in the query/request body is meant to avoid.

s0me0ne wrote:
I had thought about storing the token in the database temporarily while they are logged in ... Although I'm not sure if it would better to store the token or just store the session id in the databases.

If you're going to store some of the session data in the database you might as well store all of it there, for consistency and to avoid the issues of keeping the database in sync with the rest of the session storage. But that just represents a different mechanism for handling sessions in general.

Charles Stross wrote:
Something shared, something do, something secret, something you.