Uses of token information, there's different ways, as I mentioned, tokens could be used. You'll see four of them on the screen in front of you. Static password tokens, these are tokens that have passwords in them that are static, that are provided every time you access the token. And that token password is used again and again and again. It's okay, but the problem is, as I point out here, these could be vulnerable to replay attacks. Somebody can capture the session that you're transmitting that password through. And they can reuse that, a bad actor could, to effectively recreate the session, re-authenticate and gain access to the system that you're using. So while static password tokens may be okay, they're not the most secure and perhaps not the best implementation that we could hope for. We can offset the vulnerability to replay attacks by using session time outs. And so the system that we authenticate against may allow us to establish a session using a static password token. But only do so for, let's say, 30 minutes. And after that 30 minute period, we may have to re-authenticate, or it may allow us to establish one with an open-ended time value. But if there's inactivity for more than maybe 30 seconds, a minute, 5 minutes, variable depending on what it is we're doing, then the session will be effectively turned off, timed out and killed. And that session ID can no longer be revalidated, or reanimated and reused. You have to generate a new one. It's a one-time session with a session time out. That will help us to offset replay attack vulnerability. And so it could be a good what we call compensating control that allows us to use static password tokens. So you may want to be thinking about that. And think about for every kind of situation we're in and every kind of system we use and every kind of device we present, how would I offset that? How would I get around it? How could I defend against it? The mind of the SSCP has to be the active mind of the security practitioner. You ultimately, in other words, as SSCP candidates. And ultimately, when you are successful at taking and passing the SSCP exam, as active SSCPs in our security community, are going to be responsible on the front lines for doing these things every day. Implementing these systems, managing them, maintaining them, auditing them, all the things associated with this kind of a solution. And as the result of that, you're going to have to be very good. And not just understanding what the systems does, but how it does it and why it does it the way it does. Because if you have that in your mind, if you understand those things, you can begin to put yourself in the mind of the attacker. And you could begin to understand how the attacker may approach that system. And how they may choose to use the information they possess to try to compensate for the controls you put in place, and move around them, and effectively attack the system. And so by understanding the nature of the devices we use, how they work and why they work the way they do, we become better at providing defense. And as a result, potentially better at securing our systems. Going clockwise on the screen, synchronous dynamic password tokens. There's a timer that's used to rotate through various combinations of passwords generated through a secure cryptographic algorithm. Whatever the algorithm is that's been implemented inside the token, whether it's AES, or whether it is triple DES, or who knows what? But whatever it may be, there's a variety of algorithms. We set that up ahead of time, the token's programmed a certain way. Today, probably AES, the Advanced Encryption Standard algorithm is most likely being used. Triple DES, probably not so much. Older, potentially subject to attack and compromise, so it's kind of phased out and not really being actively used anymore, but you may still come across it. Whatever that algorithm is, that will randomly generate some sort of a combination of solutions based on a timer. And we synchronize, hence the term synchronous, we synchronize the token with the system that we're authenticating against. And that timer is used to offset and to do the generation. We go through every so many cycles, every so many minutes or seconds, or whatever it may be. The issue there can be that the synchronous solution may become decoupled, desynchronized. And as a result of that, if we can attack the time synchronization, the token may be rendered inoperable. Because if we have more than several seconds or minutes, or whatever the value is, for the time drift, as we call it, that can occur on these systems. What actually may happen is that ultimately the token may be rendered inoperable because it's no longer synchronized. And that could be a complication and a concern we have. Asynchronous password tokens, one time password generated without a clock. I know we said we'd go in clockwise order, I just rotated around and jumped, but just follow me on the bottom there. I'm going to go across the bottom row, I apologize for going out of sequence. Asynchronous password token, one time password generated without a clock. Reason I jump to this one is that this one is the opposite of synchronous. This is not going to require that time synchronization. Instead, we're going to generate a one time password from a pre-contrived list or a pre-contrived sequencing of password generation. Items that we're using, some sort of an algorithm randomly generates and never reuses. And as a result of that, we don't have to worry about synchronizing the token and the system that we're authenticating against. We just have to be, from a time perspective, synchronized. But rather, what we have to do is walk through that list of passwords we're generating. And we have to make sure that both sides understand that the password abc123 is the current one we generate on the list. And as long as that's provided, we're good. Next one will be 123def. And we have to make sure we have that thought process set up on both sides. And we walk through that list, or somehow walk through that set of solutions together, even though we're not directly synchronizing. So be aware of that. There's no time synchronization, in other words. And then challenge response token. Public key cryptography, public private key pair cryptography is what we're talking about here. Or asynchronous cryptography as opposed to synchronous cryptography or single key cryptography. Symmetric or asymmetric cryptography is what I mean to say. The idea being symmetric cryptography is going to be single key. Asymmetric cryptography is going to be dual key or public key private key pair. And so when we think about public key cryptography used to validate ownership of the private key of the challenge response token, the token is going to be given some sort of a challenge from the system that we're authenticating against. We have to then generate a response and send it back and authenticate that at the authenticating system in order to make sure that the two are paired up. And the keys effectively lock in place and produce the same results. And if the public key and the private key both used on either side to challenge and respond and generate that information jointly, if we can authenticate that both are indeed producing the same result, we know we have a matching key pair. And the only way to do that would be to possess both keys or have access to both keys. And as a result of that, we know we have the valid user on the other end of the system. Any or all of these approaches allow us to use tokens to validate identity, some more securely than others. What we have to understand as SSCPs is, number one, how they work, so having a general sense of that. Number two, the dos and don'ts of each one. For instance, that static password tokens may be vulnerable to replay attacks. That we can offset that replay attack by using session time outs, like I went through with you. And the fact that synchronous dynamic password tokens are going to require time synchronization and can be vulnerable to decoupling or desynchronizing, whereas asynchronous password tokens do not. And there is obviously a liability as well as a benefit, depending on what we choose to implement. Any or all of these have strengths and weaknesses, in other words, is what I'm suggesting to you. Making sure that as you go through, you review this information, and you study that you're aware of those strengths and weaknesses, will be very important for you. And something that you obviously want to focus on as we go through and continue our discussions.
