> From: Josh Daymont [mailto:joshdat_private] > The rand(3) function on nearly any commercial OS will be easily > guessable by an attacker. ... > > For most operating systems, the rand(3) libcall is implemented > using a linear congruential generator (LCG). These kinds of > functions are easily broken by an attacker after getting only two > known consecutive outputs. Which, in this case, the attacker would have to extract from the preimage of the digest. If the attacker can get that, Ryan has other problems. Frankly, I think his session ID algorithm looks safe, assuming a threat model where the attacker's only access is collecting generated session IDs and providing arbitrary values for the client-supplied inputs to the session ID function. I'd want to prepend or append a counter to the digest to prevent collisions, which (by the birthday paradox) will happen with probability N/2**64 where N is the number of hash values. But aside from that I don't see a practical attack, and none of the messages in this thread thus far have suggested one. Jan Lehnardt suggested adding a site-specific secret value to the preimage; that's not a bad idea, though trying to predict or force a session ID looks infeasible even without it. It's true that remote IP and user agent aren't contributing security or uniqueness, and could be dropped from the preimage. (They aren't hurting anything, though.) For uniqueness, the IP addressing tuple (local and remote IP address and port) could be used; that has to be unique for simultaneous conversations. Of course, guaranteeing unique (at a given moment) preimages doesn't guarantee unique digest values, though, so that's not terribly useful. I'd use a counter outside the digest, as described above. Michael Wojcik Principal Software Systems Developer, Micro Focus Department of English, Miami University
This archive was generated by hypermail 2b30 : Fri Jan 11 2002 - 14:26:04 PST