Security question

[JamesB]

I am half way through making a site you can only do certain stuff if logged
in to.

So far, you are logged in if there is a session variable with your username,
but I got thinking that presumably someone who worked this out could make a
cookie file with this info in and pretend to be another user. So... what's
the recommended way?
I thought of storing an MD5 hash of the login time in the session and in the
database too, then on each page, comparing the session variable to that in
the db. Theory being, if a hacker had tried making their own cookie file
they wouldnt have the right hash.

Sound reasonable? Or is session info secure enough anyway? Its not a D.O.D
site or anything, but might as well make it right from outset...
James.

[Gordon Burditt]

>I am half way through making a site you can only do certain stuff if logged

in to.

So far, you are logged in if there is a session variable with your username,
but I got thinking that presumably someone who worked this out could make a
cookie file with this info in and pretend to be another user. So... what's
the recommended way?
The cookie variable does not contain the session variables. It
only contains a key to the session variables. If there are no
sessions with the target user logged in, the hacker can't guess a
session cookie to that user. There won't be any like that to guess.
(He can try to guess that user's password, though, which may be a
lot easier than guessing the cookie).
I thought of storing an MD5 hash of the login time in the session and in the
database too, then on each page, comparing the session variable to that in
the db. Theory being, if a hacker had tried making their own cookie file
they wouldnt have the right hash.
It is not difficult to write a handler to put session info into the
database in the first place. This doesn't increase security, but
it may make it easier to do admin-like things like look at who's
logged in or clean up old abandoned sessions periodically.

Unless the hacker has access to files on the server (and then you're
REALLY in trouble, as he can probably modify your code too), the
only sessions he can fake are ones active at the time. These will
have *correct* md5 hashes, so your check does nothing.
Sound reasonable? Or is session info secure enough anyway? Its not a D.O.D
site or anything, but might as well make it right from outset...

One thing you can do: time out existing sessions, and DON'T DEPEND
ON PHP TO DO IT FOR YOU. Store the login time in the session and
check for expiration on each page along with checking for a valid
login. Make the session time as short as practical without
inconveniencing legitimate users. You might want to use the "last
hit time" rather than login time, so sessions stay active if the
user keeps clicking, but die if they walk away from their computer.
This lets you make the timeout quite a bit shorter. Beware, though,
that if users post stuff they may take quite a bit of time composing
what they post, and get irritated if their session times out.

If session security is better than user password security, the
hacker will go after the user's password (which gets him in
permanently, rather than for a short time).

Gordon L. Burditt

[JamesB]

"Gordon Burditt" <go***********@burditt.org> wrote in message
news:11*************@corp.supernews.com...

I am half way through making a site you can only do certain stuff if
logged
in to.

So far, you are logged in if there is a session variable with your
username,
but I got thinking that presumably someone who worked this out could make
a
cookie file with this info in and pretend to be another user. So... what's
the recommended way?

The cookie variable does not contain the session variables. It
only contains a key to the session variables. If there are no
sessions with the target user logged in, the hacker can't guess a
session cookie to that user. There won't be any like that to guess.
(He can try to guess that user's password, though, which may be a
lot easier than guessing the cookie).

I thought of storing an MD5 hash of the login time in the session and in
the
database too, then on each page, comparing the session variable to that in
the db. Theory being, if a hacker had tried making their own cookie file
they wouldnt have the right hash.

It is not difficult to write a handler to put session info into the
database in the first place. This doesn't increase security, but
it may make it easier to do admin-like things like look at who's
logged in or clean up old abandoned sessions periodically.

Unless the hacker has access to files on the server (and then you're
REALLY in trouble, as he can probably modify your code too), the
only sessions he can fake are ones active at the time. These will
have *correct* md5 hashes, so your check does nothing.

Sound reasonable? Or is session info secure enough anyway? Its not a D.O.D
site or anything, but might as well make it right from outset...

One thing you can do: time out existing sessions, and DON'T DEPEND
ON PHP TO DO IT FOR YOU. Store the login time in the session and
check for expiration on each page along with checking for a valid
login. Make the session time as short as practical without
inconveniencing legitimate users. You might want to use the "last
hit time" rather than login time, so sessions stay active if the
user keeps clicking, but die if they walk away from their computer.
This lets you make the timeout quite a bit shorter. Beware, though,
that if users post stuff they may take quite a bit of time composing
what they post, and get irritated if their session times out.

If session security is better than user password security, the
hacker will go after the user's password (which gets him in
permanently, rather than for a short time).

Gordon L. Burditt

Thanks for the pointers Gordon.
As you say, if user's passwords are hopeless then all of your other security
becomes somewhat redundant!
James