The CHAP and PAP authentication protocols have been a mainstay of network computing. In this video, you’ll learn how PAP and CHAP operates over the network and some of the advantages and disadvantages of using these protocols for authentication.
<< Previous Video: One-time Password AlgorithmsNext: Single Sign-on >>
When we log into a network, when we connect to a server, we need some way to authenticate ourselves. And so there’s a series of protocols behind the scenes that make sure that our username and password, or any other information that we’re providing to authenticate, is received properly and we’re able to get access to the resources that we need.
One of the first types of methods of doing this was an authentication protocol called PAP. And that stands for Password Authentication Protocol, and extremely simple, extremely basic protocol. If you recall Kerberos in an earlier video, there was a lot of encryption. There was a lot of communication to certain servers. It was a multi-headed process that took place.
PAP is nothing like that. PAP is incredibly simple in the way that it works. Everything that’s communicated, in fact, with PAP is completely in the clear. There’s no encryption here whatsoever. If I was to type my user name, [? ajames, ?] and my password, [? aprofessor ?], all of that will be sent in the clear across the network to the other side, where it would be interpreted. And then I would be allowed access or not allowed access.
Now obviously on today’s modern networks, that is a painfully unsecure way of doing things. You do not want to send especially password information in the clear. So generally, we don’t see PAP being used very often. But we are using other methods of authentication that fortunately are much more secure than this.
One of those more secure methods is one called CHAP. It stands for Challenge Handshake Authentication Protocol. This is an encrypted message that is sent across the network. Microsoft also has their own version of this called MS-CHAP, so you may see it referred to that way if you use a lot of Microsoft operating systems.
This is a three way handshake. The link is established to a server that we would want to authenticate to. And that server sends us a challenge that says, if you want to get in here, you’re going to have to prove that you are who you say you are. Our client, us, is going to respond back with not the password in the clear, but a hash of the password.
And we’re going to send that hash across the network to the other side. And at that point, the server is going to compare what it received in the hash with what it has stored as the hash of your password. And if all of those things match up, then you’re allowed access to that resource.
Even after you gain that initial access to the server, the CHAP process is not quite done yet. It will continue to ask for challenges and get responses back every so often at a pre-defined time. And your username and password is probably cached on your machine. So you generally never see this happening. But behind the scenes, it’s going to check in every so often and make sure you are really the person who would you say you are.
If we were to look at this graphically, we would probably see a message to pop up on our screen that asked for an authorization. And we would put in our name and our password. And although we’re typing in our password with what it really is, for instance, password111, we are not going to send that over the network.
The application that is asking you for this is going to hash that. And it’s going to send this. So when the server asks you to authenticate, you may send the user name in the clear but you’ll notice that your password is completely hashed when it goes to the other side. And that’s the information that the server is going to use to make sure that that syncs up.
An authentication method that was created by Microsoft is one called LANMAN. You may seen this referred to as LAN Manager. This is one that was created from Microsoft and 3Com. They were just getting into the world of network based operating systems. So this is well before Windows NT. This is well before any of our Windows Vistas or Windows Sevens.
This was a very, very early type of operating system. And it’s one that still needed a way, of course, to authenticate. So Microsoft has their own challenge response system in LANMAN. And it was very similar to what we saw with CHAP. But it was a little bit different.
For instance, it was only uppercase ASCII characters that you could only have a maximum password size of 14 characters. And notice that if you had passwords over seven characters, it split those off at seven. So if you had an eight character password, what you really had was a seven character and another one character password that it would save.
So already, the information that’s being stored is not perhaps the best one to have there from an encryption perspective. And the passwords are not salted either, which means that they’re always going to look exactly the same every time. We’re not adding a bit of randomness into the password process when we’re sending it across the network.
So there’s challenges there with keeping that secure. There needed to be different ways to look at handling this LAN Manager configuration. So Microsoft tweaked it just a little bit to try to make a few things more secure. The update that to make it more secure came with Windows NT. And this was updated to something called NTLM, NT LAN Manager.
This is what was used in early versions of Windows NT. The password is now Unicode, which means it has a lot more flexibility on the types of characters you can have in there. It could be up to 127 characters long. And it’s stored as a 128-bit MD4 hash, which is generally a lot more secure than the smaller DES hashes that were being used in the LAN Manager configuration.
But even that wasn’t good enough a new version called NTLM version two came out. This came out with Windows NT Service Pack four. And this added some additional security. We had a new password response. There was an MD4 password hash, the same as what we had with the NTLM version one.
And there was a hash of the username and server name combined with that in there. So now we had a little bit more information thrown in there to make this a little bit more encrypted as it went across the network. This means it’s not going to be exactly the same every time. There’s going to be some things that are going to be randomized when that information is hashed and sent across the network.
And there’s also this variable length challenge sent that has a time stamp, some random data, some domain name information, a little bit more details in there, so that we could make that conversation a little bit more secure during the authentication process. There are a few vulnerabilities you should probably be aware of when dealing with NTLM version one, NTLM version two. And part of this was created because there were two versions of this NTLM authentication.
Therefore, we had to make sure that older systems could authenticate. And if an older system didn’t know how to authenticate with NTLM version two, then it may be locked out of the system. So unfortunately, a number of Legacy systems kept not just the NTLM version two password, which was pretty secure, but it kept the older insecure NTLM version one password as well.
The challenge is that if somebody gained access to that NTLM version one database, they would be able to have a much easier way to decrypt and figure out what people’s passwords were. We also had a problem with NTLM, where it was vulnerable to what we call a credential forwarding attack. What this essentially meant that we could use the credentials of one computer to gain access to another computer.
Now obviously, that’s not what you want to have happen as well. Microsoft has introduced bug fixes and updates to their operating systems to avoid these types of situations. But it’s something you should be aware of if you’re using a number of these Legacy authentication systems.