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.