[13647] in cryptography@c2.net mail archive
Sessions
daemon@ATHENA.MIT.EDU (Jill.Ramonsky@Aculab.com)
Mon Jun 16 10:27:52 2003
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
From: Jill.Ramonsky@Aculab.com
To: cryptography@metzdowd.com
Date: Mon, 16 Jun 2003 14:39:12 +0100
This has got nothing whatsoever to do with session fixation. It _has_
however, got something to do with security. In particular, with
authentication.
[Moderator's note: Actually, it seems to have everything to do with
session fixation. --Perry]
I may be ignorant about a few things but I'm learning fast, and I still
think the following question is worth my asking (and someone answering)
because I'm actually thinking of using this idea on a real web site. At the
very least, it seems to me that it ought to be more secure than NOT tracking
the IP.
> I've come up with a (very simple) defence against session hijacking and so
> on. It's probably flawed (I admit I'm not an expert on these things), so
if
> someone could please tell me why it won't work, I'd be very grateful.
>
> When the user logs in, the server stores the client's IP address in a
> session variable (so it's stored at the server end - the client just gets
a
> session id). Authentication of subesequent pages is assumed only if the
> client's IP address matches the IP address stored in the session variable
> corresponding to the client's session.
>
> Is this secure? If not, why not?
Jill
> [Moderator's Note: you might want to read the original paper again. It
I didn't receive the rest of this moderator's note so I don't know what it
was going to say. My apologies for not having changed the subject line from
"RE: Session Fixation Vulnerability in Web Based Apps", and for not making
it clear that this is a different and unrelated thread.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
