Hi Rainer, > -----Original Message----- > From: Rainer Jung [mailto:rainer.j...@kippdata.de] > Sent: Friday, February 14, 2014 5:57 PM
> Nice article. > > The table in the article says for 16 bytes and 500000 session ids the > probability of a duplicate is far below 10^-18. Ah, thanks, I didn't notice the probability table when I first looked over the article. > In my case they used 13 > bytes, but even with only 8 bytes the table says the probability is > between 10^-6 and 10^-9 so still pretty small. I expect the higher > duplicate occurance on the target system being strongly influenced by > the quality of /dev/urandom. But I must confess that I don't have enough > data about the original situation. > > Can you explain what you mean with "using an extended setof characters > to encode the ID instead of simply hex"? AFAIK, a Random Number > generator produces random bytes (as the simplest random value is a bit, so it > can produce a series of 2^n random bits). Using hex characters is just another > way to describe those generated bytes. > > We have to encode the id as a cookie or url encoded value. The current > session id generator always does it using hex digits. In my case the > total length of the session id is limited to 26 encoded chars. So if I > have to remove some of them for the new additional data I want to add to > the ID, the remaining chars might be to few for good > randomness/security. If I instead of using hex digits use all chars > (lower plus upper case) and digits, I can encode 60 values in one byte > instead of only 16. Thus more randomness fits into the same encoded id > length. OK. > Fortunately I don't have to prevent any long term collisions, just > reduce the rate without increasing session id length. Therefore I prefer > not to keep state for a long time including tomcat restarts, or do > remote (database) calls to check ids whenever a new one is generated. While adding some information like the current time probably reduces the possibility for collisions, I'm concerned about the security implications. I understand that your requirement for avoiding collisions of session-IDs between 30 days is to ensure that a client that gets a specific session-id does not try to reuse it some time later and, by chance, hits a session that has been assigned to another user but uses the same session-ID. However, e.g., if some attacker knows that you add a time information to the session ID, he could just try to re-use the session-id and add some timestamp values, as the time value isn't a random value that cannot be predicted, so I don't see a security benefit here. (Maybe one could then run a hash function over this combination of random bytes + timestamp so that the attacker doesn't know the original session-ID, but this would probably cause some other problems.) Personally, the only secure way to avoid collisions over a period of time that I can think would be to store the generated IDs somewhere and check them when they are generated. However, one would need to increase the number of bytes that are used for the session-ID to ensure that the number of possible session values at any time is at least as high as when not checking for collisions. However, when viewing this from an wider perspective, I don't think that such collisions are a real problem - the client could just generate some random value by it self and try to use it for a request, to see if the session-ID is currently in use. More important would be that the number of bytes that is used for generating a Session-ID is so high that a client has a vanishing chance of hitting a valid session-ID, regardless of whether the value that he uses is one that the server generated previously, or one that is randomly generated by the client. (just my two cents, as Mark E. would say) Regards, Konstantin Preißer --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
