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.