Session Security

Anon

Hello,

Is PHP session secure? I was wondering a case stated below and not sure if I am correct.

Case:
Whenever a person comes to my page, he will be assigned a session ID, say "12345" (just for example). Then whatever data I get from this person are stored as session variables associated to session ID 12345.

Meanwhile at the same a 2nd person come to my page, whose session ID is assigned to be 67890. BUT IF he manually type in the session ID 12345 in the URL using the GET query string, I assume that the 2nd person will actually be in the same session as the 1st person, which means that he can use the session variables of the 1st person.

Am I correct? Is this a security hole? Or is my concept toward session just wrong? Please correct me.

In general, how do people use session to create a member login system? You don't want to store any password as cookies or ust GET query strings. Can anyone give me some advice?

Thanks a lot!

Anon

I recently started using Prattle message board. Steve just added an encrypted session key using MD5 to ensure session security. Here\'s what it does:

$cryptphrase = $cryptphrase . dirname($PATH_TRANSLATED) . $HOSTNAME;

function makehashid()
{
global $cryptphrase;
global $uid;
return md5(\"$cryptphrase $uid\");
}

// function to validate whether a uid is valid
function isloggedin()
{
global $uid;
global $hashid;
return ($hashid == makehashid($uid));
}

You can see it takes the user id (from the database once you log in) along with your hostname, and makes a hashid with it. Then the session checks that hashid every time to make sure it matches.

Joseph wrote:

Hello,

Is PHP session secure? I was wondering a case stated below and not sure if I am correct.

Anon

You can also not rely on passing the URL in the query string. Of course this means using cookies, but its better then having the query string have a users unique ID. For example, what happens if that user copy and pastes that URL to send to a friend? Think about it. How many times has one of you just passed a URL to someone else you know?

You could also have a cookie + unique ID combination for better security.

The method posted above (and my own idea) above is not very scalable, since encripting data is an expensive procedure on the server side. Sessions in general are not scalable, they are fine for small to mid size applications. But what happens when you move your site to a server farm? How do you keep session state then?

Interesting topic of discussion. I've been lately involved in discussions on how to make our session management scale up to millions of users, but still haven't come up with a "great" solution.

Anon

But what happens when you move your site to a server
farm? How do you keep session state then?

You use the (provided) functions to override the default
storage method and store the session data in your database.

Anon

You can also store the session data on a shared directory that all servers can access.

Anon

1) the session ID is sufficiently long and random to prevent anybody from just
typing a sessionid and actually getting a valid session.
In order to take over a session this way, a hacker would need to have access to your computer to read the sessionid.

2) Before you do anything "secure" with sessions, you must validate the user by username and password. If the user enters the correct information, you send a cookie to the user and give that cookie an encrypted value.
from then on, every time the user accesses "secure" pages, you check to see if that cookie is set to the proper value. If not,then this user is not who he claims to be.

This is described in more detail in one of the columns on this very site.

Anon

How reliable is that database? I would think that you would need another farm of DB servers to provide 99% uptime. Then it also comes down to network traffic, disk I/O, RAM, OS, etc.

Anon

Getting very much off topic here.

Anon

ALl of you mentioning cookies...
what is cookies are disabled? You can't rely on cookies

Anon

You can rely on cookies, provided you check that the user has cookies enabled.

If you don't want to use cookies you'll have to create some other
way of making sure that the user is who he says he is.
Instead of storing the info in a cookie, you could create a new encrypted
key, or a random number, that is sent along with every transaction
made to the server.
Then the server can check if the random number received from the user
matches the one he sent to that client before.