OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Steve Mcilwain (smcilwain_at_bizjournals.com)
Date: Sun Aug 25 2002 - 20:19:55 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    To summarize what I understand after following this thread is that you need
    to grant a client a session ID as a temporary authentication token, after
    the client successfully authtenticates (hopefully via SSL or TLS). This
    prevents the client from having to log in with each page and also allows you
    to store per-session data on the server.

    The problem is that session ID's are vulnerable to replay-attack and much
    discussion has been centered on how to prevent someone from getting the
    session ID in order to replay it. Others have suggested that the best
    approach is to prevent the session id from being replayed.

    As far as hiding the session ID, I see little to no value in it. Sure,
    putting the value in a cookie makes it a little harder than in the URL, but
    neither is secure. It's like arguing that one unlocked door is more secure
    than another unlocked door because one door is hard to see. So the
    objective should be to prevent client session ids from being replayed. I
    think the previous suggestions presented in this thread to generate new
    client session ids with every page request solve the problem - a stolen
    session id cannot be reused.

    I have little experience using client certificates for authentication, but
    could a client certificate also be used to associate with a session id,
    preventing a client without that certificate from using the session id?

    Steve