"Schnitzer, Jeff" <[EMAIL PROTECTED]> writes:
> Yes that's true if the monotonically increasing value is added to the
> random number _before_ the hash... and even worse, there is nothing that
> guarantees that two numbers won't hash to the same value so we're back
> to the duplicate session id problem.
>
> What I was suggesting is adding the integer to the session id _after_
> hashing:
>
> ASDFASFDASFDASF000000012
> [hashed random][counter]
>
> This would guarantee that every session id is unique, and wouldn't
> require any synchronization (operator ++ on any integer smaller than a
> long is guaranteed atomic, right?).
The standard fix for this is to use a cryptographic pseudo-random
number generator, such as Java's SecureRandom. SecureRandom
automatically seeds itself from allegedly random system data.
the probability that two sufficiently long random numbers
(e.g. 16 bytes) will collide is vanishing. (E.g. with a 16-byte
session ID, you'd have to generate > 2^60 session IDs to have
a reasonable chance of collision.
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]]
http://www.rtfm.com/
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
