Hi guys
Yeah I see your point.
Ok, so after a bit of digging around, I have found the following...
The session cookie, is called PHPSESSID which obviously holds the sessionid.
Now then, is it possible and I assume it is, to hold more than one value in this cookie.
I intend to do the following.......
Modify the script above, so that it first creates a random number of so many characters, use this to encrypt the sessionid, and another field to the database, which holds the generated random number so that you would be able to check the validity.
Send both the sissionid and encrypted sessionid in the cookie.
Make sense?
Cheers guys
Session security!
Moderator: General Moderators
Yes, I mis-spoke to some degree. The MAC-ing of the sessionid protects primarily against users changing the cookie manually, without knowledge of a captured cookie.penny wrote:can't see how would you like to prevent hijacking of a sessionid with MACing? if someone can use others sessionid, and you MAC it to check if it's correct, then you still get corret value! 'cause sessionid is correct, and $SERVER_SECRET is constant (or at least always the sam for one sessionid). The only values you could MAC to get level of sevurity you write of is MACing IP and sessionid BUT there are methods that allow hacker's computer to identify itself with others IP adresess.nielsene wrote:Because if the user can simply update/change the sessionid they may be able to "hijack" another user's session, therby assuming their permissions and identity. MAC-ing the session ID makes it very easy to detect this mode of attack.Recoil UK wrote:Hi again
But the only thing in a session cookie is the sessen id, and as thats allready a unique value, whats the point.
I can see why you would want to use a MAC on a normal cookie, just not a session cookie.
L8rs
So if someone will REALY WANT to hack into someone's session it won't be imposible for him. AND if he want's it so badly that he steals others sessionids, using fake IP wouldn't be a problem for him
Penny
Yes, a person who can line-snoop to capture other user's session ids will likely be spoof IP's easily as well. However, it does make things harder for the attacker. You will need to take additioal measures to protect against this more knowledgeable/targetted attacks.
Hi guys
So what about a changing value that you hash against? wouldnt this help?so long as you remember the value then it has to be better.
Another question, what infromation does a cookie hold, other than the sessionid?
domain
But what about the time? does it hold the expiry time?
Or does it hold the lifespan time?
Because if it holds the lifespan time, then thats no good either, because its constant.But the expiry time would be usefull.
L8rs
So what about a changing value that you hash against? wouldnt this help?so long as you remember the value then it has to be better.
Another question, what infromation does a cookie hold, other than the sessionid?
domain
But what about the time? does it hold the expiry time?
Or does it hold the lifespan time?
Because if it holds the lifespan time, then thats no good either, because its constant.But the expiry time would be usefull.
L8rs
Just to point out with all this discussion of MAC'ing and sessions and cookies, that the first step in securing a website is SSL. Without SSL, pretty much everything you are doing is moot. With SSL, it makes it that much stronger. No, SSL is not 100% guaranteed to prevent hacks, but it will help you stop a lot of them.
Hi
With a normal cookie, you can specify if it is to be sent using ssl, is this still possible with session cookies?.
As far as MACing some type of variable against the sessionid, I still cant see the point, just about the only thing you can do, is to make the sessionid thats generated as hard as possible to predict.
Currently, I dont think the PHP way of using the date and time is good enough. To predict this, some only has to find out how long the sessions last for, and then he can narrow down the possible values.
You need a constantly changing randon number in the mix, and a good crypt algorithm.
L8rs
With a normal cookie, you can specify if it is to be sent using ssl, is this still possible with session cookies?.
As far as MACing some type of variable against the sessionid, I still cant see the point, just about the only thing you can do, is to make the sessionid thats generated as hard as possible to predict.
Currently, I dont think the PHP way of using the date and time is good enough. To predict this, some only has to find out how long the sessions last for, and then he can narrow down the possible values.
You need a constantly changing randon number in the mix, and a good crypt algorithm.
L8rs
A given cookie can only hold a "single" value. By default, the session cookie holds the value returned by a call to session_id(). You can, however, manually set the "session_id" to some concatenation of values. I suggest a combination of a session indentifier + expiration_time + MAC(of the previous two), where '+' represents concatenation with a deliminator to avoid splicing attacks.(A "+" is often used as the delinator as it doesn't appear in MD5 output nor in common session id schemes.)
You can set the ssl bit in the php.ini file for session cookies, as can you configure the reported cookie expiration time. However the cookie expiration time can not be trusted as 1) its user changeable and 2) it requires the client to expire the cookie, with no server side check. (That's why I suggest incorporating the expiration time directly into the cookie payload and protecting it with a MAC).
You don't need to use a different key for the MACing every time. Most sites people here write would probably be acceptable to change the MAC key 1-3 times a year. If you wanted to be very paranoid, you could change the MAC for every session, but it makes verifying the session more difficult.
The advantage of MACing a variable is to detect tampering of the protected variable. If you don't see that as a benefit, then I can understand why you don't see the point of MACing.
You can set the ssl bit in the php.ini file for session cookies, as can you configure the reported cookie expiration time. However the cookie expiration time can not be trusted as 1) its user changeable and 2) it requires the client to expire the cookie, with no server side check. (That's why I suggest incorporating the expiration time directly into the cookie payload and protecting it with a MAC).
You don't need to use a different key for the MACing every time. Most sites people here write would probably be acceptable to change the MAC key 1-3 times a year. If you wanted to be very paranoid, you could change the MAC for every session, but it makes verifying the session more difficult.
The advantage of MACing a variable is to detect tampering of the protected variable. If you don't see that as a benefit, then I can understand why you don't see the point of MACing.