]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Friday, January 10, 2003 1:34 PM
Subject: Re: Duplicate session IDs are *common*
Glenn Olander [EMAIL PROTECTED] writes:
I think you may have misunderstood. I'm just pointing out that, from a
user's
perspective, a good solution
Impressive.
Could you make a small modification and run the same test with
20 concurent threads ? I checked the code and we have plenty of
syncs, but you never know.
Interesting - java.util.Random is not synchronized, so it is very likely
that 2 threads calling the method at the same time will
Costin Manolache wrote:
Could you make a small modification and run the same test with
20 concurent threads ? I checked the code and we have plenty of
syncs, but you never know.
OK -- for this I went to the horse's (or maybe I should say, cat's)
mouth with the same result -- collisions still
On Fri, 10 Jan 2003, Phil Steitz wrote:
Except that hash( i++ . secret).i is generally a lot cheaper and easier to
Unfortunately, hashing blows away guaranteed uniqueness (one-way =
not 1-1), so if your last step is a hash, you will need to keep the
Hence the concatenation with 'i'. Or
On Fri, 10 Jan 2003, Costin Manolache wrote:
I find it amazing that 2 people reported beeing hit by meteors (duplicate
session ids ) in the same week.
Make that 3; I've seen this as well; I suspect this is becauce tomcat
saves the sessions across restarts; and then happens to re-generate them
On Sat, 11 Jan 2003, Phil Steitz wrote:
Sorry, missed that. You are correct (also about hashing being a cheap
way to get randomization).
No, no; just unpredictability.
An interesting challenge is how to keep the uniqueness bits either
short enough so that the random bits give strong
on 2003/1/9 10:28 PM, Remy Maucherat [EMAIL PROTECTED] wrote:
I can't reproduce an id collision so far.
Remy
I'm sure you aren't running the same level of concurrency that say a company
like Maxis is running. Duplicate the environment and the problems become
clear.
-jon
--
StudioZ.tv /\
Using a modified version of Tim Funk's Collide.java, I ran the
following dispersion test (using Sun's Linux jdk's 1.3.1_03 and 1.4.1_01):
1. Generate n session id's.
2. For each pair of generated id's, count the number of matching
characters in the two strings (i.e., the number of positions where
I was unable to reproduce a collision too. I took ManagerBase and
converted it to a standalone java program (by stripping out code) to see
if I might get duplicates. But I keep running out of memory near 1
million sessions.
java Collide 1
Generates 1 ids. (Change the number to change
On Thu, 9 Jan 2003, Schnitzer, Jeff wrote:
One thing to contemplate is that if you have 100,000 sessions and you
get 10 new sessions created every second, that's the equivalent of 1
million inadvertent hack attempts every single second. Granted that's
still small compared to the total size
Note that you would need 1 million sessions that are active
at the same time - if a session expires and the id is reused
there is no harm.
If I leave my browser open and go for lunch and someone else gets my
expired session id, I return and continue browsing, wouldn't that cause
problems?
Here's a follow-up on the bug report I submitted that started this thread.
1) We confirmed the problem is a duplicate session id.
Luckily we were logging session id's. It took a lot of hunting through
access logs, but we did indeed find two sessions which were started a
couple of minutes apart,
Glenn Olander [EMAIL PROTECTED] writes:
5) The strength of the PRNG is largely irrelevant
As a user, I wouldn't trust any solution which lacks a check for
duplicate session id's, regardless of the strength of the PRNG.
This doesn't seem to me to be a plausible position in view
of the fact
Jim Jagielski [EMAIL PROTECTED] writes:
Eric Rescorla wrote:
Glenn Olander [EMAIL PROTECTED] writes:
5) The strength of the PRNG is largely irrelevant
As a user, I wouldn't trust any solution which lacks a check for
duplicate session id's, regardless of the strength of the
At 10:42 AM -0800 1/10/03, Eric Rescorla wrote:
Jim Jagielski [EMAIL PROTECTED] writes:
Eric Rescorla wrote:
Glenn Olander [EMAIL PROTECTED] writes:
5) The strength of the PRNG is largely irrelevant
As a user, I wouldn't trust any solution which lacks a check for
duplicate
The check will verify that the session id doesn't duplicate another
active session.
If the session expires - it is still possible ( even if extremely unlikely )
that a user will reuse the same browser window and get into someone's else
session.
I think this is as likely as someone using a
Eric Rescorla wrote:
Jim Jagielski [EMAIL PROTECTED] writes:
Eric Rescorla wrote:
Glenn Olander [EMAIL PROTECTED] writes:
5) The strength of the PRNG is largely irrelevant
As a user, I wouldn't trust any solution which lacks a check for
duplicate session id's, regardless of
On Fri, 10 Jan 2003, Jim Jagielski wrote:
But it doesn't change the fact that randomness != uniqueness, which is
what Glenn's point was I think.
Just as an example; doing on issue
syncronized count++;
id = count.ipaddr
add port if you must :-)
gives you a
I think you may have misunderstood. I'm just pointing out that, from a
user's
perspective, a good solution requires two elements:
1) a good PRNG, such as secureRandom
2) a uniqueness guarantee
I'm not saying a PRNG is unneeded. I'm just saying a good one like PRNG
is good
enough as long as it
Jim Jagielski [EMAIL PROTECTED] writes:
Of course, as you said, it depends on the range and the timespan.
But it doesn't change the fact that randomness != uniqueness, which is
what Glenn's point was I think.
Perhaps not from a theoretical persective, but from a practical
perspective it does.
Glenn Olander [EMAIL PROTECTED] writes:
I think you may have misunderstood. I'm just pointing out that, from a
user's
perspective, a good solution requires two elements:
1) a good PRNG, such as secureRandom
2) a uniqueness guarantee
I'm not saying a PRNG is unneeded. I'm just saying a
Costin Manolache [EMAIL PROTECTED] writes:
Eric Rescorla wrote:
Jim Jagielski [EMAIL PROTECTED] writes:
Eric Rescorla wrote:
Glenn Olander [EMAIL PROTECTED] writes:
5) The strength of the PRNG is largely irrelevant
As a user, I wouldn't trust any solution which lacks
I saw another problem that had similar symptoms to
duplicate
session ID's. My application was getting collisions
between different users having the same session ID
using
tomcat 4.0.5. I found that the request headers were
not
being cleared out when they were recycled so that
cookies
from a current
On Fri, 10 Jan 2003, Glenn Olander wrote:
1) a good PRNG, such as secureRandom
Why does it need to be securely random; surely unpredicatable is good
enough ?
2) a uniqueness guarantee
count++ +:+myip+:+myport
is also quite unqiue :-)
DW.
--
To unsubscribe, e-mail:
ID provides a statistical probability of collision so low that
there is no need to explicitly check for uniqueness.
Or just add a syncronized i++ to make sure.
Dw.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Dirk-Willem van Gulik [EMAIL PROTECTED] writes:
On Fri, 10 Jan 2003, Glenn Olander wrote:
1) a good PRNG, such as secureRandom
Why does it need to be securely random; surely unpredicatable is good
enough ?
Securely random and unpredictable are effectively the same thing.
-Ekr
--
Dirk-Willem van Gulik [EMAIL PROTECTED] writes:
ID provides a statistical probability of collision so low that
there is no need to explicitly check for uniqueness.
Or just add a syncronized i++ to make sure.
Yes.
There's nothing wrong with what you propose, but it's sort of
like saying
Securely random and unpredictable are effectively the same thing.
Depends on your definition; one-way-function((count++) + (secret)) is
quite unpredictable; expcet for those knowing the secret. Secure random
generators give you a value which is unpredictable for all. And are a lot
more
On 10 Jan 2003, Eric Rescorla wrote:
There's nothing wrong with what you propose, but it's sort of
like saying maybe I should wear a helmet at all times
because a meteor might drop on my head. Sure, it could happen,
btu it's not the thing I'd worry about.
Except that hash( i++ . secret).i
Eric Rescorla wrote:
Dirk-Willem van Gulik [EMAIL PROTECTED] writes:
ID provides a statistical probability of collision so low that
there is no need to explicitly check for uniqueness.
Or just add a syncronized i++ to make sure.
Yes.
There's nothing wrong with what you propose, but
Costin Manolache wrote:
I find it amazing that 2 people reported beeing hit by meteors (duplicate
session ids ) in the same week.
I find it odd that it actually happened ...
You're right - a counter is better than time. It'll duplicate the counter
if tomcat is restarted - so probably the
Combining two messages...
Dirk-Willem van Gulik [EMAIL PROTECTED] writes:
Securely random and unpredictable are effectively the same thing.
Depends on your definition; one-way-function((count++) + (secret)) is
quite unpredictable; expcet for those knowing the secret. Secure random
Costin Manolache [EMAIL PROTECTED] writes:
Eric Rescorla wrote:
Dirk-Willem van Gulik [EMAIL PROTECTED] writes:
ID provides a statistical probability of collision so low that
there is no need to explicitly check for uniqueness.
Or just add a syncronized i++ to make sure.
Yes.
Dirk-Willem van Gulik wrote:
On 10 Jan 2003, Eric Rescorla wrote:
There's nothing wrong with what you propose, but it's sort of
like saying maybe I should wear a helmet at all times
because a meteor might drop on my head. Sure, it could happen,
btu it's not the thing I'd worry about.
Craig R. McClanahan wrote:
On Wed, 8 Jan 2003, Aditya wrote:
Date: Wed, 08 Jan 2003 22:36:58 -0800
From: Aditya [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Subject: Re: Duplicate session IDs are *common*
On Wed, 08 Jan
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
Remy Maucherat [EMAIL PROTECTED] writes:
- A MD5 hash occurs after getting the SecureRandom. This looks like a
mistake, and decreases the quality of the random a lot, but given the
quality of MD5, that shouldn't be noticeable in the real world.
I think that the MD5 is pointless but it shouldn't
On 9 Jan 2003, Eric Rescorla wrote:
Remy Maucherat [EMAIL PROTECTED] writes:
- A MD5 hash occurs after getting the SecureRandom. This looks like a
mistake, and decreases the quality of the random a lot, but given the
quality of MD5, that shouldn't be noticeable in the real world.
I
Dirk-Willem van Gulik [EMAIL PROTECTED] writes:
On 9 Jan 2003, Eric Rescorla wrote:
Remy Maucherat [EMAIL PROTECTED] writes:
- A MD5 hash occurs after getting the SecureRandom. This looks like a
mistake, and decreases the quality of the random a lot, but given the
quality of MD5,
of a truly randomly generated
128-bit number, but I wouldn't run a banking application on it.
Jeff Schnitzer
-Original Message-
From: Remy Maucherat
Subject: Re: Duplicate session IDs are *common*
Date: Thu, 09 Jan 2003 02:57:23 -0800
We have to make sure the problem is real before
Schnitzer, Jeff wrote:
I've already patched the 4.1.12 version we are running with the fix that
is currently in CVS. Unfortunately our only notification of when the
problem occurs is when users notice (which they probably wouldn't unless
they acquired an administrative session) and choose to
there is no harm.
Costin
Jeff Schnitzer
-Original Message-
From: Remy Maucherat
Subject: Re: Duplicate session IDs are *common*
Date: Thu, 09 Jan 2003 02:57:23 -0800
We have to make sure the problem is real before putting out any
advisory. You should patch the ManagerBase class
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
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
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
On Wed, 08 Jan 2003 19:37:28 -0800, Costin Manolache [EMAIL PROTECTED] said:
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
On Wed, 8 Jan 2003, Aditya wrote:
Date: Wed, 08 Jan 2003 22:36:58 -0800
From: Aditya [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Subject: Re: Duplicate session IDs are *common*
On Wed, 08 Jan 2003 19:37:28 -0800
47 matches
Mail list logo