Re: [OT] How does tomcat handle session ids?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Peter, On 2/8/18 11:30 AM, Peter Kreuser wrote: > Forgive the top-post! :/ iOS mail lets you type anywhere you want! > 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. The container has no "logout" mechanism, the application must implement it -- usually by invalidating the session. Invalidating the session removes that session from the list of valid sessions. There is no "logged-in flag", at least not in the container. The application may have such a flag -- possibly in a database? The user may simply leave the site without formally logging-out -- like closing the browser window. The server has no idea that the user will never return. That's why sessions expire after a certain period of inactivity... 30 minutes is the default. > That is essentially not a requirement to tomcat but to the > developer who implements the webapp. The container must implement the timeout, but the application must implement the explicit-logout. > 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. Session id reuse is in fact not a big deal conceptually. Except you don't want to use an MRU queue and intentionally re-use session ids in the near future, because... > PS: Please also review “session fixation” as a side note to this > problem. If I get session id abcd1234 and then log out, and Tomcat implements a "session id re-use" policy, then someone in the very near future will end up using the session id abcd1234. Knowing a user's session id is equivalent to being logged-in as that user (in the absence of any other authentication mechanism, of course), so I simply have to wait a few minutes and then try to use session abcd1234 again. Once I can see that it's been re-used (because I don't get a login prompt when requesting a protected resource), I can take control of that user's session. This is why it is important to require sensitive operations to re-authenticate the user. For example, changing the current password to a new one should require that the old password be provided as proof that you are STILL who you said you were when you logged-in. Many mitigations for session-fixation attacks exist. Some examples I can think of off the top of my head: 1. Use source-IP as an additional factor. When the user logs-in, record their IP address in the session and validate it for every subsequent against that session. No match == invalidate the session. 2. Generate a nonce when the user authenticates (logs-in) and store it in the session. Also send that value as a cookie to the user. Match the cookie value against the session-value for each request. This *sounds* like just another re-implemenation of the JSESSIONID cookie, but it's not. The session-id can be "fixated" (by predicting the session id), but the nonce is independent of the cookie. The attacker would have to predict not only the session id (which can be done by tricking the victim into using a chosen session id) but also the nonce generated by the application, which should be extremely difficult. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlp8ip4dHGNocmlzQGNo cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFg1DA/+K/ZKa2gLkCskcl8c O0YsT7fu4e+9gRJkM4oQJdTG5FgweplXz+9kj8v3N+xIdWsX4GbmfdnlRuiA68Hp x2aZYoO/phngj9uD5odUohtOFDxU/xnTOS3w5WPdicSxvHV5Ctdi+0Rn+9EeQESK LaBjy0O98xDhY7nO2doCCebtm07JuNVdTJd9Itu6KvYavOJOGnrTWnFTREwc1inD RWHn+npEF4ue2TktqS9xD8d1RKQkAQVazg+WPKjOHgZxKALI4p24zdAIImUIob6Z +YmIbXcSHbU0sjM7FIciCdVm4fEL9HSaI9qcUwvlFQW5UL7FRocc/7RRthzYhvov U1cPKi7tQgJKT6MyVWEwMA5E4MaZ/uX0oU+WAfARcEBV1NdSqBVoDKI+lrX18IKy Ff1AP03sycwT6xBWPQlAkKBIqxRDeNI4W0ysmzEYkxSa7uzm0oCBHVJ05BQdBksO pszI5EJv1sN6n4V/QrVsbYFXQT1XYmPy5j5uBh6z6/NPVaPyMY/AZRokAfsfhgGC xOQc0QSNZZXH/v6Lc+DukhNOCBJD+KAhS0NDbUmcf3bJ7KTQVoupY4djdrGz+t1M bUrUZDhyXu5w+1pjJL7o40iDiksc8zKVY17FU+BoM+Hd0DscEN+HWfWCZ2C6dcJP 1mVfPAV5+Rf6iaPafbh27Q67p2Q= =LOii -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] How does tomcat handle session ids?
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 > : > > -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
Re: [OT] How does tomcat handle session ids?
-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