Ok, based on that, how about: md5( ( remote_port ) . (microtime() + time()) . (total bytes transferred to clients in last hour) . (current pid) . ( remote_ip )) Notes: 1) I know the remote_port and remote_ip are controlled by the user, but they are there just to add to the mix. I.E. add more data for the MD5 to hash off of. 2) If no one has used the system in the past hour, then you in theory have a slight problem with having a "0" in that place. Perhaps can be fixed by doing a If (!BytesTransfered in Last Hour > 0) BytesTransferedInLastMonth. 3) On apache, 1 pid may serve 10 different requests before dying. Perhaps we could also randomize with the number of processes currently running on server? Or maybe number of open connections? 4) I think that is all my comments for now. Ryan M Harris ----- Original Message ----- From: "Glynn Clements" <glynn.clementsat_private> To: "Ryan M Harris" <rmharrisat_private> Cc: <secprogat_private> Sent: Friday, January 11, 2002 3:49 PM Subject: Re: Safe session IDs > > Ryan M Harris wrote: > > > First of all thank you all for the help. I sent a reply directly only to > > people who had mentioned something that I can't use, and gave a reason. > > > > I see I have to make myself a little more clear. Unfortunately because of > > specification restraints I must rely on generating a unique, unpredictable > > number on ANY operating system and I cannot expect the user to install 3rd > > party randomizers hardware or software (such as Yarrow, though it looks > > good). > > > > 1) It must be written in PHP but because of the features I need I can't use > > its built in session handler. > > 2) I cannot rely on /dev/urandom because windows does not support that. > > 3) Microtime() returns time() + microseconds since last second > > Note: just because it returns a time in units of microseconds, that > doesn't mean that it increments in individual microseconds. The actual > resolution may be much worse. > > > 4) The MD5 is for mangling of the data just so it is harder to guess also > > serves as a convenient way of ensureing safe passing via browser. > > > > Based on these constraints, is there a good way of doing this? I could use > > a built in PHP function called UniqID, but it seems to only be md5(rand()) > > Also note that, unless it is seeded with some unpredictable value, any > PRNG (e.g. rand()) will be worthless if each invocation of the script > uses a separate process. > > Ultimately, you *MUST* have some external source of entropy, and a > clock is unlikely to be sufficient unless it is very high resolution > (even a true microsecond clock may not be sufficient). > > As Christian suggests, REMOTE_IP + REMOTE_USER_AGENT contains so > little entropy as to be worthless. Consider two users using a popular > ISP which provides both the browser and the proxy. > > If the script is run on a system where the sole remaining source of > entropy is a 100Hz clock (e.g. Linux/x86), then you *will* get > collisions occasionally. > > As Christian also points out, if you don't have something which is > *guaranteed* to differ for each invocation (e.g. a pid), then the > probability of a collision will be non-zero. Note that you may be able > to manufacture unique IDs if you persistent storage available (i.e. a > writable directory). > > That may not be fatal if you can get the probability low enough; > modelling the system as a poisson process should give you the actual > collision rate. > > -- > Glynn Clements <glynn.clementsat_private> >
This archive was generated by hypermail 2b30 : Fri Jan 11 2002 - 13:53:06 PST