On Wed, 8 Jan 2003, Costin Manolache wrote:
> Date: Wed, 08 Jan 2003 19:37:28 -0800 > From: Costin Manolache <[EMAIL PROTECTED]> > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: Duplicate session IDs are *common* > > Schnitzer, Jeff wrote: > > > For whatever reason, be it the seed algorithm or the hashing algorithm > > or something else that degenerates the randomness - the duplicate > > session ID problem is very, very common. > > > > I discovered this problem because a few of our users suddenly found > > themselves with the sessions from administrative accounts. Luckily they > > alerted us instead of causing mayhem. There were at least three > > separate occasions of this in the last week - that we heard about. > > > > We have also seen this a number of times with other game components - > > users suddenly finding themselves logged in as other people. > > > > It probably explains the recent post to tomcat-user included below. > > > > Here at my company this problem caused about as much panic as a wildfire > > breaking out in the machine room (read: LOTS). I humbly suggest raising > > the level of concern a bit; post a security bulletin, etc. > > What version of tomcat ? Are you on Linux ? What randomClass are you using ? > How many sessions are usually generated ? > > The default is java.security.SecureRandom - and should give enough > randomness. There is a change on head ( that would work with 5.0 - but > it can be backported ) that allow you to use /dev/urandom ( or another > source - it can be a pipe or something like that ). > Even though duplicate session ids are *possible* (because Tomcat doesn't check for it), the 99.9% cause of this kind of a problem is application programming errors like using an instance (or static) variable in a servlet to store per-request state information. That only works if the servlet never processes more than one request at a time. Based on my experience, I don't believe this is a *common* problem, but it is a problem that needs to be addressed. > > Costin > Craig -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
