I was not refering to a way to timeout inactive session but instead to allow the
administrator
to override this policy by a stricter one and allow a maximum active session time if
he decides to implement it.
Which means a user may do what they have to do on your site for x amount of minutes
and then they will have to create a new session to continue.
The behaviour for timing out inactive sessions would simply complement this policy.
-----Original Message-----
From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]]
Sent: Mon 19/08/2002 10:27 PM
To: Xavier Spriet
Cc: [EMAIL PROTECTED]
Subject: RE: [PHP-DEV] trans-sid warning?
This is not the issue we are discussing. PHP already times out inactive
sessions, and in this particular case the session has even been created
yet, so there is nothing to time out.
-Rasmus
On Mon, 19 Aug 2002, Xavier Spriet wrote:
> (I might have sent this one twice again...)
> ------
> why not simply allow a maximum amount of time a session can exist (let's
say, 25 minutes).
> This could be customised or even disabled by the administrator so it won't
be a flea to regular users, and even though it won't be bulletproof, it will make
things considerably more complicated for the attacker.
> Sending a link and hoping it will be clicked in the next 25 minutes is just
trying your luck.
>
> Also a good web developer aware of this will most certainly put a little
informing text such as:
> You are currently loged in as: you loged in with the following
IPaddr/Uagent: blablah.
>
> Xavier.
>
> -----Original Message-----
> From: Sascha Schumann [mailto:[EMAIL PROTECTED]]
> Sent: Mon 19/08/2002 8:50 PM
> To: George Schlossnagle
> Cc: Rasmus Lerdorf; Yasuo Ohgaki; [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] trans-sid warning?
>
>
>
> > To play devil's advocate, pure cookie based authentication is not a
> > panacea. If you allow users to put things like javascript on your
site,
> > or if you have users who exploit ie bugs like the about: cookie
domain
> > bug from last year, cookies can be stolen and session hijacked.
pure
> > cookie auth is definitely a good thing, but does not provide safety
in a
> > number of 'real world' applications.
>
> Yes, I pointed that out in an earlier discussion about this
> topic. A online-banking site could for example check the
> browser for certain types of common vulnerabilities and post
> a nice "please upgrade" dialogue.
>
> This would exclude IE by default though, because there are
> quite a load of unfixed, publically known security bugs.
>
> http://www.jscript.dk/unpatched/ listed them, but the page
> seems to be down now. Google still finds
>
> http://www.jscript.dk/unpatched/MS02-023update.html
>
> "Yesterday I hosted a list of 14 publickly known unpatched
> vulnerabilities, today I host a list of 12 such. It can still
> be found at http://jscript.dk/unpatched/
>
> - Sascha
>
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
