|
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
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
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]