An authentication method that was created by Microsoft
is one called LANMAN.
You may see 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 7s.
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 can 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 and 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 LANMAN configuration,
so Microsoft tweaked it just a little bit
to try to make a few things more secure.
The update to 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,
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 LANMAN configuration.
But even that wasn't good enough.
A new version called NTLM version 2 came out.
This came out with Windows NT Service Pack 4,
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 1,
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 timestamp, 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 few vulnerabilities you should probably
be aware of when dealing with NTLM version 1, NTLM version
2, 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.
If an older system didn't know how
to authenticate with NTLM version 2,
then it may be locked out of the system.
So unfortunately, a number of legacy systems
kept not just the NTLM version 2 password,
which was pretty secure, but it kept the older, insecure NTLM
version 1 password as well.
The challenge is that if somebody gained access
to that NTLM version 1 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 within 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.