> To avoid it, one has to roll one's own state management, for
> example by providing one's own cryptographically strong login
> label in the Urls in the web page one generates in response to
> a login, the label acting as primary key to a table of
> currently active logins.
When I've done login a
--
On 14 Jun 2003 at 21:42, Ben Laurie wrote:
> The obvious answer is you always switch to a new session
> after login. Nothing cleverer is required, surely?
I had dreamed up some rathe complicated solutions.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQ
Ben dude wrote:
> The obvious answer is you always switch to a new session after login.
> Nothing cleverer is required, surely?
Well particularly the issue is your login URL should not accept an
existing session identifier supplied by the browser (what the author
of the session fixing paper calls
James A. Donald wrote:
> --
> James A. Donald wrote:
>
>>>This flaw is massive, and the biggest villain is the server
>>>side code created for Apache.
>
>
> Ben Laurie
>
>>This isn't the case. I analysed several sites I work on for
>>attacks of the type described when this paper first cam
--
Rich Salz:
> > The following environment variables are exported into SSI
> > files and CGI scripts:
> > SSL_SESSION_ID The hex-encoded SSL session id
On 14 Jun 2003 at 18:24, Daniel Carosone wrote:
> The problem is that this is not especially useful in
> practice, if your client is I
--
James A. Donald wrote:
> > This flaw is massive, and the biggest villain is the server
> > side code created for Apache.
Ben Laurie
> This isn't the case. I analysed several sites I work on for
> attacks of the type described when this paper first came out.
> None of them were vulnerable.
James A. Donald wrote:
> --
> On 12 Jun 2003 at 16:25, Steve Schear wrote:
> http://www.acros.si/papers/session_fixation.pdf
>
> Wow.
>
> This flaw is massive, and the biggest villain is the server
> side code created for Apache.
>
> When you login to your bank, your e-gold account, your
On Fri, Jun 13, 2003 at 09:58:32PM -0400, Rich Salz wrote:
> The following environment variables are exported into SSI files
> and CGI scripts:
> SSL_SESSION_ID The hex-encoded SSL session id
The problem is that this is not especially useful in practice, if
your client is IE. Essentially, you
At 02:24 PM 06/11/2003 -0700, David Honig wrote:
At 12:42 PM 6/11/03 -0600, Anne & Lynn Wheeler wrote:
>actually, if you had a properly secured DNS then you could trust DNS
>to distribute public keys bound to a domain name in the same way they
>distribute ip-addresses bound to a domain name.
.
