Dear all, Forgive the top-post!
Going back to the root-cause of the question: In my opinion the security requirement stems from the idea, that a logout must invalidate the session and thus make the data practically inaccessible - instead of just removing a typical loggedin flag and keeping the once used session with stored values alive. That is essentially not a requirement to tomcat but to the developer who implements the webapp. If that would always be the case (and of course for tomcat to keep track of active ids) would make session id reuse not a big deal. My 2cts. Peter PS: Please also review “session fixation” as a side note to this problem. Peter Kreuser > Am 08.02.2018 um 17:14 schrieb Christopher Schultz > <ch...@christopherschultz.net>: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Mark, > >> On 2/8/18 4:49 AM, Mark Thomas wrote: >>> On 07/02/18 23:49, Alex O'Ree wrote: >>> I was recently perusing security implementation guides and ran >>> across one that required that sessions id's be "destroyed" after >>> use and not reused. From my understanding, it looks like the >>> java/tomcat/servlet equivalent is the jessionid. I'm assuming >>> this is probably a randomly generated id but I honestly don't >>> know without digging through the code base. >> >> It is a securely generated random ID. >> >>> If it is a randomly generated UUID it's a pretty safe assumption >>> that a duplicate id is very unlikely and that reusing a session >>> id for a different tomcat user session is also very unlikely. Is >>> this correct? >> >> Correct. > > I did some math on this once when I was trying to figure out how to > "size" some one-time-use tokens that I need to generate for $work. In > my case, they really *must* be (a) ONE-time use (no, really) and (b) > as difficult as possible to randomly-guess a valid token. > > So the question was "how many bits do I need to satisfy both of these > conditions"? > > I started with Tomcat's default session-id size as a baseline. The > default session id size (in bytes) is 16[1]. > > The number of possible 16-byte tokens is 2^(8*16) = 2^128 = > 340282366920938463463374607431768211456. That is a /really/ big number. > > It's so big that, if I were able to generate and test 1024 tokens per > second, it would take me 3846145821136909354467034317940 days to try > all combinations. That's ~10530173363824529375679765415 years. That is > a /lot/ of years. > > We ended up choosing 15 bytes because, when base32-encoded, it > fully-fills a 24-character token without any shortfall. So we are > limiting ourselves to a mere 160677694150154562006832 years for an > exhaustive search. C'est la vie. > > As for the distribution of the generated bytes, that depends upon the > implementation of SecureRandom. Java says that > java.security.SecureRandom meets the requirements of FIPS 140-2 > section 4.9.1[2]. > > Given the hilarious farce that is FIPS, it won't surprise you to find > out that (a) the hyperlink from Oracle's documentation to the FIPS > 140-2 reference does not work, (b) the hyperlink from Oracle's > documentation to the FIPS 140-2 reference is in fact 404 Not Found, > and (c) section 4.9.1 of the current FIPS 140-2 reference is unrelated > to random-number generation. If you follow the rabbit-hole long > enough, you will lose your mind. ;) > > - -chris > > [1] > https://tomcat.apache.org/tomcat-8.5-doc/config/sessionidgenerator.html# > Standard_Implementation > -----BEGIN PGP SIGNATURE----- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlp8d3sdHGNocmlzQGNo > cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFgchxAArwmFELprgINIeVSY > SzZZ0kEexVub9VkBw8jsgbsfBOqeIGgFUXLZIf9aKkzX2gowu8KpU3C5eJ6Z8+Dc > SDesMyNujG2+DS/6v6eNF8zZhaYBfafh/V/YCmX2sf1IZ44uyDuLjr9D+85a3nxI > EvKVJESHFoaRLQP2GRY/x5t6NWFNtt7BI9OIXKbsDBX+Toz079/aoxKioCnNk1xq > /5r8dOyTEE5ST9Z4n+dzLXYOqvWA65VVfoIQCDkA2pkkFI//TD2orOjYgz0ZtsCl > dFygrblkrv5CFYU1pfjHw89UT0Gtsov99Ip0PE2CRJBo+NiCSbERrSCCMhzTjtHC > fsmpBQl9ZgZRjdgq8mZOr5L6y3N3xSoAULvj0McTIdULZlQL/qQfOcenrwsZseIy > WMywV+EDRLSNqmwoIGAEXJNI3OFaN1owehxtusYbS39f6d0DN1P8Op6E8O9RcggU > htqO/qwuWDY0u99ho6dd3DU2vnCHrqo+VrnTIabFPg2fKv7MtXRBPoslLCCLYPvk > G6yLk0MvHiWkoqTnxSBQoa6EVvjP0W0EZHUiYGwNTGIGPUFsaf93kaKv8E3yr0kg > bt1p2F9xe4R8fTu/3Cm7iv2DWo6N2C7MV6xTF/kAKANyjSEXDaTvxnCluOfR/8YS > lz81Fbclj3JOOyu9fhJlTLes1F4= > =xn/y > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
