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.