Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: rain forest puppy (rfpwiretrip.net)
Date: Wed Mar 06 2002 - 00:50:38 CST
> OK, but then it all depends on how secure the site server is. If someone
> gets the secret they have the key to any session if brute-forcing
> microtime() is used.
Yes, but if someone is into your site enough to get the secret, odds are
they can also retrieve the list of current sessions too (via DB, file,
A server compromise will yeild a session ID list, secret or no secret.
> But if the secret depends on something from the user and something
> from the server, wouldn't that be more secure for all?
Could be. Typical is to embed the IP address of the user into the
> Well if the granularity of thread wakening and sleeping is finer than
> the speed that people can type, as in the Java example, then it seems
> that the System environment is in control of the user's chunk of the
server-side generator will. Why go with the less-supported approach,
when the end security is the same?
> Anyway, I can't think of how someone could get in and tamper
> with someone else's front end in the first place. Because at that point
> they haven't logged in. There isn't a session to steal yet. But maybe
> YOU can think of a way! :>)
Cross-site scripting could allow for a malicious site to tamper the client
and compromise the client-side process.
I'm sorry, but I do not trust client-side logic to do something as
sensitive as generating a session ID.