Welcome back. Today, we will continue our discussion
about session management. Specifically, we'll be discussing the threats from an attacker who tries to use brute force in order to guess session IDs. Then, we're going to talk about some mitigations for this threat. We will describe what the session ID guessing attack
might look like, and then we're going to have a little bit of a chat on how to approximate the time to guess a session ID based
on its bit length. Now I'm going to talk a little bit in
a hand waving manner, and I won't go into
any math proofs here. However, I have given you resources that you can
see for yourself to go over more detailed information
of why the formula for approximating this time to guess session IDs is the way it is. Then we're going to
talk about ways of mitigating these
guessing attacks. By the end of this lesson, you'll be able to discuss session management
threats including guessing session IDs by brute force and how
to mitigate them, and you will be
able to approximate the time it takes to
guess a session ID. Let me show you what I mean. When an attacker tries to brute force guess,
existing session IDs, what they do is they
basically try to initially look at what an existing
session ID looks like. So they might log
in and attempt to interact with the server
as a regular user. Then, when they have seen what
the session ID looks like, they might try to then guess by creating different forms
of the session ID, and then interacting with the server once they've
generated that session ID. So they do this
very, very quickly, and they try to perform as many guesses per
second as possible. So session ID should be generated by the server as close
to random as possible. However, if the
session ID bit length that the server
uses is too short, this can still be easy
for an attacker to guess. So you might wonder, well, how is it that we can determine
how long it takes for a session ID with
a specific bit length to be brute forced
by an attacker? OWASP has a pretty
good explanation, and they have this formula here. As you can see at the top, it is two to the exponent B, then plus one as a numerator. Then in the denominator, it is two times A times S. Here the variable
B is the number of bits of entropy in
the session identifier. Now, I will go into a little bit more detail
about this because explanation from the OWASP site here might not be intuitive. So I'm going to give
a little bit of detail as to how they could have
gotten that numerator. But moving on, so A is
the variable that represents the number of guesses that an attacker can try each second, and S is the number of valid session
identifiers that are valid and available to be
guessed at any given time. So let's look at what a specific
example might look like. So if you have a 64-bit
length session identifier, that means that we, according to the
information in OWASP, we assume 32 bits of entropy. So that means B is set to 32. For a large website, we can assume that
the attacker tries 1,000 guesses per second and that there are 10,000
valid session identifiers at any given moment. So based on these assumptions, we can calculate that
a rough estimate for the time it takes
for an attacker to successfully guess
a valid session identifier is roughly seven minutes. So how that comes about is
when you plug the numbers in, you will see that you will
come out at 429,496 seconds. Now, at 1,000
attempts per second, that is 429 seconds or
roughly seven minutes. So it takes roughly seven minutes for an attacker to guess a valid session ID if the session ID bit length
that you're using is 64 bits. However, if we carry on
with the example and assume a 120 bits
session identifier, so based on that, B is the number of
bits of entropy. So we would take that and have the bit session
identifier length. Now, with a very large website, an attacker might try 10,000
guesses per second with 100,000 valid session
identifiers that currently exist and are
available to be guessed. So based on those assumptions, the expected time for an
attacker to successfully guess a valid session identifier
is greater than 292 years. So a little bit more
detail can be found in this source link here in
the slide from OWASP. Now, you might be wondering where does that numerator come from, that two to the power
of B plus one. So this notion of bits
of entropy mentioned in this formula might not
seem very intuitive. You might be asking why is B half the total number of bits
in your session identifier. It's because of the concept
of the birthday paradox. Now, the birthday
paradox helps us to explain how many numbers
you need to generate from a set or a range
of discrete numbers before you generate one that you have already
generated before. Otherwise known as a collision. Now, I won't get into the proof
of the birthday paradox, but the URL link in this slide
from betterexplained.com is really helpful in understanding
the birthday paradox. Now, in that resource URL link
that I mentioned, there's a nifty
calculator that you can use to play around
with this concept. So for example, here's a calculator from
betterexplained.com, where I played around
with it to give a little bit more context
for where B comes from. So if you look at the URL link
in the previous slide, you will see a calculator that can help you prove
this to yourself. So in the context of
the birthday paradox, the total set of possible
numbers that is generated for a session ID
is two to the 128. For example, if we were using a session
ID bit length of 128 bits, so that means the total of possible session IDs
is two to the 128. Now, further, we have a number that is
represented by 128 bits, as I mentioned earlier. So this means that based
on the birthday paradox, the number of times that
you will need to run a random number
generator to generate a number with 128 bits in order to eventually
start generating numbers that you have generated before will be two
to the 64 times. So again, you need to run a random number generator two to the 64 times in
order to eventually create or generate a number that you have generated before with this number that is having
a bit length of 128 bits. So in summary, that's
why the exponent B is half the total bit length number
of the session ID. So little bit further in
a little bit more detail. Here in this calculator, we have a chance to generate
a pair at 50 percent. So this is our probability that we will generate
a collision. If we had more than two to the 64 numbers having
a bit length of 128 bits, then you will start having a higher likelihood of
generating a collision. So what are the mitigations for these brute force
guessing attacks? So as we mentioned earlier, if you used a session ID with a bit length that is
greater than 128 bits, then it will basically slow
down these brute force guessing attempts because it takes hundreds of years to guess. Another thing that
you can do is to associate your session IDs
to their TLS connections. So in a little bit more detail,
on the server side, you can tie or associate the session ID that
is currently being used by the client with the current TLS
connection of that client. So even if an attacker
were to be able to guess the session ID
of a client, the attacker wouldn't
be able to use the session ID unless
it was being used over the original TLS connection or if it was used over
a renegotiated TLS connection, where the session ID was
given on the first try. Also, you want to make
sure that there is only a one-to-one relationship between a session ID
and a TLS connection. In other words, it shouldn't
be possible to use a session ID on more than
one existing TLS connection. So in summary, we talked about brute force session
ID guessing attacks, and then we talked a little bit about approximating
the time it takes to guess an existing session ID given a session ID bit length. Then we talked about two mitigations that
you can employ in order to stop brute force
session ID guessing attacks. From this lecture, I want you to concentrate more
on the mitigations rather than approximating
the time to guess a session ID. The mitigations here are more
important to understand. That's it for now. Thank you.