-----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
