Ryan M Harris wrote: > 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. Certainly, they will help protect against innocent random collisions. > 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. If you can obtain that information, couldn't you also obtain the total number of bytes transferred in the system's entire life? That would solve the problem altogether (provided that the value didn't wrap e.g. at 32 bits). > 3) On apache, 1 pid may serve 10 different requests before dying. There's also the issue that the session ID remains valid beyond the life of the process which generated it. So the PID could be wrap and get reused in generating a later session ID while older session IDs are still in use. > 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. If you have some value which *never* repeated (e.g. an invocation counter), then simply using MD5(counter + secret) would be enough (to protect against hacking, as well as random collisions) provided that: a) the secret is good enough, and b) MD5 is as strong is as widely believed. An invocation counter wouldn't be that hard to implement[1], provided that you can write to some file. Due to locking, efficiency could become an issue if the rate of session creation is high (although, if you're considering the possibility of an hour elapsing without any access, that's not likely to be an issue). In the absence of an invocation counter, you're basically looking for the next best thing, i.e. something which will very rarely repeat. -- Glynn Clements <glynn.clementsat_private>
This archive was generated by hypermail 2b30 : Sat Jan 12 2002 - 08:16:52 PST