Re: [PEN-TEST] HTTP Secure Session State Management

[Mark Curphey <mark () CURPHEY COM>]

With the risk of this getting dangerously off topic to application security
design .......

OK maybe its the "some more magic" that is confusing me or maybe I need to
rephrase the Q ;-)

To me the contents of the cookie payload should be a unique session ID (a
pseudo random string) that is held in a table in the application somewhere,
maybe call it a "state table" and valid this for the session only (i.e.
timeout valued). That should be encrypted with a key that only the
application can encrypt / decrypt. When the cookie is read its value is
decrypted to reveal the session ID that is valid if the timing is correct
thus maintaining state. With a timeout there will always be the possibility
for replay I guess. This way the timing is set at the server and compared to
the server time. This way a successful attack would only reveal a time
limited session ID and not a perpetual username and password; i.e. if you
break the crypto you could hi-jack a session but not an account.

As for client IP's, I agree that too many users sit behind NAT'd firewalls
for this to uniquely verify any users. I have seen too many security
conscious companies and indeed so called security companies, use Secur-ID
with a VPN solution that authenticates a user from an IP address. Try
connecting from VPN clients like Secure Remote from a big ISP and you will
see what I mean. All too often you have been granted access past the
perimeter by another kind sole with his / her SecurID token and are straight
through to an Exchange web client login prompt etc
-----Original Message-----
From: Penetration Testers [mailto:PEN-TEST () SECURITYFOCUS COM]On Behalf
Of van der Kooij, Hugo
Sent: Tuesday, December 26, 2000 12:13 PM
To: PEN-TEST () SECURITYFOCUS COM
Subject: Re: [PEN-TEST] HTTP Secure Session State Management


On Sun, 24 Dec 2000, Mark Curphey wrote:

> IMHO - I am not sure how this solves the problem at all of secure session
> state. Sure you can set the cookie as a secure cookie (i.e. cant only be
> transmitted over https) , but if I am reading you right (and I may not be)
> the cookie is still set on the client machine and what ever you set can be
> replayed by any user of that machine. I can't see how SSL and token based
> authentication adds value here to session management.  All this adds is a
> encrypted tunnel to set a cookie.

The cookie should be computed from information like:
 - username
 - password
 - client IP
 - date/time
 - Some more magic
 - expire date/time

So this results in a key that is set by the server and used by the client
to cache username/password authentication for a short while. (You don't
want to type it 5 times per page with one-time passwords.)

Take a look at the mod_auth_radius code to get a grasp of it.

The actual security is still based around the use of one-time passwords.

Hugo.

--
Hugo van der Kooij; Oranje Nassaustraat 16; 3155 VJ  Maasland
hvdkooij () caiw nl     http://home.kabelfoon.nl/~hvdkooij/
--------------------------------------------------------------
This message has not been checked and may contain harmfull content.