(Anyone else, is there a module that already does this?)
That misses two things: random data is not unique and random data is
scarce.
The thread started where someone else wanted a cheap way to generate
difficult to guess and unique session ids. It went on around how using a
random function doesn't provide uniqueness and eventually ended up where
we're at now (verified sequential IDs). Part of the issue is that the
output from a digest (SHA1, MD5) or random data is not unique and cannot
ever be expected to be. So if you want uniqueness, you should use
something that produces values without looping - like simple iteration.
You could use some other number series but that's just pointless since you
don't need to keep your session IDs secret and it will just confuse the
next person to look at the code. You also run out of numbers faster if you
{in|de}crement by more than 1.
A lot of other smarter people can tell you why random data is scarce. Just
accept it. /dev/urandom is not an infinite font of quality entropy. If you
use too much then you fall back to simpler algorithms that will enter into
loops which are highly non-random.
So what I said was keep some random data secret for a bit, use it for the
hashes and after a while get new random data. A malicious attacker can
attempt to brute-force your secret during the period that the secret is
still valid. Once the secret is invalidated then the attacker has to start
the key-space over again. This is like asking distributed.net to start
over every few minutes. While distributed.net would eventually make it's
way through vast keyspaces for a single secret, it can't keep up with
volataile secrets.
Josh
Simon Oliver <[EMAIL PROTECTED]>
05/07/2002 10:53 AM
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Cheap and unique
> [EMAIL PROTECTED] wrote:
> >digest source might be able to locate the bits just by trying a lot of
> >them. I would expire them after a while just to prevent that from
> >happening by stating that if there is a 15 minute session, new random
bits
> >are generated each five minutes.
I missed the start of this thread, but how about generating a new id (or
random bits) on every vists: on first connect client is assigned a session
id, on subsequent connects, previous id is verified and a new id is
generated and returned. This makes it even harder to crack.
--
Simon Oliver
