I've been following this conversation and I'd like to clarify whether my
idea (since I and others want to do this as well) would be use an
incrementing counter for uniqueness. Then also store a bit of secret
randomness, concatenate both values together and create a digest hash.
That hash would be sent along with the sequence as well. This would allow
uniqueness and prevent guessing since the digest would have to match as
well. Depending on my paranoia I could either get fresh random bits each
time (and have a good hardware source for this then) or keep it around for
a bit and throw it away after a period.
Does that sound right?
Josh
Perrin Harkins <[EMAIL PROTECTED]>
05/06/2002 01:15 PM
To: Ken Williams <[EMAIL PROTECTED]>
cc: OCNS Consulting <[EMAIL PROTECTED]>, [EMAIL PROTECTED], David
Jacobs
<[EMAIL PROTECTED]>
Subject: Re: Cheap and unique
Ken Williams wrote:
> If you have the additional requirement that the unique values shouldn't
> be easily *guessable*, that becomes a very hard problem, precisely
> because "random" and "unique" are such poor friends. Usually people
> just cheat by generating a large random ID such that the probability of
> it being already-used is low, and then they check all the previous IDs
> to make sure.
The requirement to prevent guessing is usually aimed at security and
preventing "session hijacking" and similar attacks (and believe me, this
kind of attack is very common). Another way to do this is to use a MAC
like MD5 or SHA1, as described in the Eagle book and O'Reilly's CGI
book. This makes it very difficult for an attacker to generate a valid
ID, even if the sequence of IDs is predictable.
- Perrin
