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.