Re: [OT] How does tomcat handle session ids?

[Christopher Schultz]

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

[Peter Kreuser]

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?

[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

Re: How does tomcat handle session ids?

[Mark Thomas]

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.

> The action of destroying the session id server side (again without looking
> at the code) is probably just a string that is eventually gc'd. Is that
> correct or is it something more sophisticated?

Also correct.

> Anyhow, I figured I would ask the tomcat community on this one.

HTH,

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

How does tomcat handle session ids?

[Alex O'Ree]

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.

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?

The action of destroying the session id server side (again without looking
at the code) is probably just a string that is eventually gc'd. Is that
correct or is it something more sophisticated?

Anyhow, I figured I would ask the tomcat community on this one.