Re: Security question
Available news archives: comp.lang.tcl - comp.lang.python - comp.security.firewalls - sci.crypt - comp.lang.php - comp.lang.javascript
Google
 
Web news.hping.org


comp.lang.php archive

Re: Security question

From: JamesB <jamesb@jmb.is-a-geekWhoDoesntLikeSpam.com>
Date: Sun Sep 25 2005 - 11:33:59 CEST

"Gordon Burditt" <gordonb.srm7n@burditt.org> wrote in message
news:11j8edvcja6g603@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
Received on Tue Oct 18 02:27:49 2005