So we're talking about different ways that we can authenticate ourselves remotely. One of the ways that we do have to mention and one of our protocols that we do have to mention our is chap now chaps stands for challenge handshake, authentication, protocol and chat allows us to essentially create is a one way authentication for a remote access to a in client.
Now, when we're sitting when we're sending challenge, when we're sending a chap message and we're authenticating via chap, essentially, what we're doing is we're sending a We have a known shared. We have a known shared secret key from our side on our side and on the in client side
that we both know this May isn't typically something like the user's password.
So were we have our user name, and we also have our password that we want to authenticate with. But we don't want to send our password over the network. We haven't
We haven't done any sort of exchanging of any keys so that we can encrypt our messages back and forth with each other yet, so we haven't authenticated ourselves. We haven't We don't I can't encrypt our messages yet, so We don't want to just send our password out in the air. Clear text. So how do we
How are we able to authenticate ourselves
without sending this password clear text? Well, what we're going to do is, instead of sending this password clear text, we're going to send a hash of the password. Remember, Are the hash is of our passwords? We aren't able to derive the password from the hash because the hash is the password. Put through a one way mathematical algorithm
and it gives us our string of our hash string.
What are in in server is going to dio is when we first attempt to initiate a session. The in client where we're trying to connect to is going to send us a challenge. That's the challenge part of this handshake, the challenge, part of chap
and with a combination of. And then once we receive the challenge, we're going to take both the challenge and are known password.
Put them through the hashing algorithm and we'll get one inch result. Well, so what we have are two variables. Put him into the hashing out, put them into the hashing algorithm and get our one way result. We need both the challenge and the password to put them into the hashing algorithm in order to get the correct answer that we can pass along.
And we can only get this correct hash to pass along. If again, we both have the challenge
and the password. And even if the challenges sent clear text, we can't derive the password from the hash and the challenge alone. So we need to have again both of these things. We need to have the shared secret secret. We need to have the password on our end.
So this prevents us from having to send that password clear text. We make that we take the challenge. We take the password
we had create a hash from both of them and we now have a response that we can send back to the inn server. The in point. The remote server now takes this and evaluates it against what it has in its records. And then if it sees that everything is good, then it's goingto let us pass through
hat. So, chap, it does not send our credentials clear text, which is wonderful. We never want to send our we always want to avoid sending our credentials clear text, if at all possible. Because that's opening up a surface for someone to potentially see our passwords. However, chap does not verify our en pointe,
Remember, a chap is a one way authentication.
So if we're sending our authentication to somebody chat does not, does not verify, it doesn't the other in point does not have to authenticate tow us. It doesn't verify that they are who they say they are, so we could be sending in connecting to someone who's just Impersonating our remote in point. So that's why
we now have M s chap M s chap is Microsoft enhanced chap. So Microsoft challenged handshake authentication protocol an M s chap. We have Amos chap version one inversion to the main difference between M s chap and chap is that M s chap in
includes two way authentication.
So not only are we authenticating to the remote point, but the remote point is also authenticating tow us. So we both know that we're both off indicating to each other. So we both have proven that we are who we say we are. We're not connecting to someone on the other side that is
Impersonating who we think that they are, who we think that we're connecting Thio We're not connecting to a malicious in client.
So that's why that's a big benefit over. That's a very, very strong benefit over just standard chat.
So again, M s chap has version one in version two.
The main distinction between version one and version to that we need to be aware of is that version two is only works on Windows Vista or above. So M s chap, if we will only be able to use em. It's chap version two on a machine that is running the Vista operating system or above. However, with
the Windows X p operating system reaching end of life
back in April, that's that should be something that we should be migrating away from. Anyway, we should be migrating toe ofhis the operating system or later. So this it shouldn't be too much of an issue if we're using Windows operating system migrating over to M s chap and then eh Miss chap version, too.
Next we have eat extensible authentication protocol. Now, eat isn't really a authentication protocol in and of itself. But what is it is a framework for our authentication. What this does is it allows us to have a standard standardized protocol that we can use
for different devices for different types of authentication. That meat we may. D'oh
whether we're authenticating with W p a to a 22.1 x e t l s. We need to have some way. We need to have some framework that we can authenticate ourselves even before we have an I p address. Remember, with a 22.1 X, we don't get an I p address until after we authenticate.
So we need some way that we can at the data link layer at the late layer to let level
authenticate and have some sort of protocol to communicate this authentication with before we even get an I P address before we're even moving at that layer three level. So that's what he does.
So it's our framework for authentication sustainer das authentic rate authentication method, and we can configure devices to authenticate are over to our network authentication method, so eat allows us to set up devices and allows them to communicate
over are different the network authentication methods such as our 802.1 x or are empty or are
e T l s. That's why there are so many different types of eat methods because there's different those different authentication protocols. Slightly change how we're using this extensible authentication protocol. So if we're utilizing a 22.1 exit, we're use a lot for utilizing transport layer security T l s. We need to have
specific EEP protocol
that works with that authentication method so that we can trans weaken,
we can send and receive our authentication. We can authenticate ourselves properly just at this layer to level just with a standardized method that really isn't hardware dependent so that we can have different types of devices authenticating over our network. We can have different types of wireless access points
authenticating with our radius servers, we can have different types
of local clients authenticating with our wireless access points. So eat again. When you think of extensible authentication protocol, think of a framework for authentication, not a not a self contained authentication protocol, but more of a framework which allows us to use
and allows us to standardize our multiple different types of authentication protocols
that we've been talking about so far.
So thank you for joining us here today on cyber today we went over a lot of material in this particular particular module. We talked about authentication. What is authentication we talked about? We had our little quick
primer on our how encryption works and how we use encryption. Asymmetric encryption versus symmetric encryption. How we use encryption with P. K. I. How we use it to set up certificates and how you use it toe have public keys and private keys. We talked about how we can transition that knowledge of public he's and private keys
into how different authentication methods work,
such as Kerberos, how we can use radius and tak us. We moved on and we talked about ah, lot of the ways that we can even utilize radius and tactics. We talked about our 802.1 x we talked about our chap R. M s Chapin are eat.
So this was a very, very large section with a lot of information from the non technical overview of what authentication is to the nitty gritty of how encryption works and how a little bit on how it works on the mathematical side, with
the algorithms and the keys and the actual data that we're trying to encrypt.
So hopefully this gave you a bit more deeper on a little bit deeper understanding of how user authentication works and how it's not just a simple as taking a user name and password, sending it over the network and getting a green, green light or thumbs up that we could connect to the network. There's a lot that goes on behind the scenes.
There's a lot that goes on with passing certificates,
mutual authentication and verifying that not only are we who we are, who we are, who we are and who we are, is what we say we are. But also the incline that we're connecting to and who were remotely authenticating with is who they say that they are,
so that we can make sure that we're not authenticating ourselves to someone who is maliciously
trying to take our authentication packets so that they can replay it to someone else.
So again, we thank you for joining us, and we thank you for taking time and going through this this quite long module we had on all these different user authentication information. And we hope to see you here next time on cyber.