Hello everyone. For this lesson,
we're going to talk about the first issue of using
Personally Identifiable Information or
PII to compose web application session IDs.
First off, we're going to give a brief overview of
why using Personally Identifiable Information to
compose web application session IDs is
an issue and then we're
going to talk about a mitigation for this.
At the end of this lesson,
you'll be able to explain why not to use
PII to compose session IDs. Let's begin.
The reason why using
Personally Identifiable Information to
compose your web application session IDs
is problematic is,
first of all this information
because it could be found in
application logs or your session data
might not be properly encrypted,
one way or another an attacker
can get at this information.
Because of this and because PII or
Personally Identifiable Information looks
like there is a general pattern to this,
an attacker, given enough time and resources,
will eventually be able to guess this information.
For example, I've modified
an example given from chapter seven which is
called attacking Session Management in
the book called The Web Application Hacker's Handbook.
These examples from this book in general
come from the two authors' experiences.
What they found for example,
is something of the following form.
For example, a session token can appear to be random.
Like what you see here in the following in this slide.
But looking a little bit closer
the way this data looks it looks,
like you could try to decode it.
Basically hex decoding because
it looks like it's hex encoded.
So an attacker could try it out and see what they get.
If they were to do that they
would see the following user data.
It says user equals inewton,
where app equals to admin and date is equal to 10/9/18.
In other words, attackers can
guess and determine that there's a regular pattern
to these kinds of session tokens and see that
the session token is eventually
made up of user information.
From the book example in Chapter seven,
which I've mentioned here,
sometimes session tokens are made using
concatenation of users first or last name,
user's email address or user's account username.
These are what not to do.
It can be tempting to use
user information as a session ID because then you can
end up saving some time performing
lookup for more information based on session ID.
However, this is a big risk that
you take if you make your session IDs in this manner.
A general strategy is to generate
tokens that are hard to guess.
Use a pseudo-random number generator to generate
your session ID and
don't use any user identification data.
In summary, we've talked about this first issue of
using PII to compose a session ID.
So don't do that.
A better way is to use
a good pseudo-random number generator
to generate the session ID.
That's it for now. Thanks for listening.