> 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,
etc).

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
prehashed data.

> 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
> secret.

That's not portable. Java/javascript will not work for all users. A
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.

Scared,
- rfp

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