Challenge - Response authentication in Windows

Specifically, we're talking about LanMan and NTLM responses.
LanMan is really for pre-NT4 clients but has been included for backwards compatibility since then.

Format for challenge-response authentication

1. Client sends a type 1 (NEGOTIATE_MESSAGE) to server, advertising its capabilities.
2. Server sends type 2 (CHALLENGE_MESSAGE) which includes supported features and the challenge itself.
3. Client replies with type 3 (AUTHENTICATION_MESSAGE) which contains information about the client including domain and user name plus 1 or more responses to the challenge.

LanMan responses

1. The ASCII password is converted to upper case.
2. It is then null padded to 14 bytes.
3. Split into 2 x 7 bytes.
4. These are used to create 2 DES keys.
5. Each of these keys is used to DES-encrypt the constant ASCII string, resulting in 2 x 8 byte ciphertext values. These 2 ciphertext values are concatenated to a 16 byte value. THIS IS THE LM HASH.
6. The 16 byte LM hash is null padded to 21 bytes.
7. This is split into 3 x 7 bytes.
8. These values are then used to create 3 DES keys.
9. Each of these keys is used to DES-encrypt the challenge in the type 2 challenge message. It results in 3 x 8 byte ciphertext values that can be concatenated to form a 24 byte value. THIS IS THE LM RESPONSE.

Weaknesses

• Converted to upper case so all of that complexity is lost.
• If password is 7 characters or fewer, the second value is null, so straight-away half of the LM hash is compromised.
• Not true one-way encryption as password can be obtained from the hash.
• Since LM hashonly changes when password changes, susceptible to pass the hash attacks, where an attacker uses the hash directly to authenticate to a server rather than having to brute force the hashes to obtain the clear text password. This is also true for NTLM authentication. Both NTLM and LM are password equivalent so if you can get the hash from the server you never need to know the actual password.

If the user's password is > 15 characters then the DC will not store the LM hash so the LM response cannot be used to authenticate the user. The LM response is still generated but a 16 byte null value is used as the LM hash in the calculation and then ignored by the server.

NTLM v1

1. Server sends 8 byte challenge.
2. Client uses a shared secret between the client and server, specifically one of the hashes (LM or NT) to return a 24 byte result of this computation.
3. NTLMv1 computations are usually made for both hashes with both 24 byte results sent to the server, unless you configure it not to.
4. Server verifies that the client has computed the correct result. This assumes that they then have possession of the secret and so are authenticated.
5. Both hashes produce 16 byte values.
6. 5 bytes of zeroes appended to them.
7. Separated into 3 x 7 bytes (56 bits). Each of these 56 bit values is used as a key to DES-encrypt teh 64 bit (8 byte) challenge. The 3 encryptions are reunited to form the 24 byte response.

NTLM v2

1. Server sends 8 byte challenge.
2. Client sends 2 x 16 byte response.
3. This response is the HMAC-MD5 hash of the server challenge, a randomly generated client challenge, and a HMAC-MD5 hash of the user's password and other identifying information.
4. The first response is shorter: it's an 8 byte random value for the client challenge. To verify this response the server must receive as part of the response the client challenge. The 8 byte client challenge is appended to the 16 byte response to make a 24 byte package.
5. The second response is a variable length client challenge which includes the current time, an 8 byte random value, domain name and some standard stuff. The response must include a  copy of this client challenge and is therefore of variable length.

NTLM Weaknesses

• As pointed out above, it's susceptible to pass the hash attacks.
• In Feb 2010 several flaws in the Windows implementation of NTLM were proved: one attack included the ability to predict the random numbers/challenges generated by the protocol. These flaws were fixed by MS010-012.

Why Not Just Use Kerberos?

Kerberos relies on a trusted third party. If one is not available (for example where a client is not a member of a domain, local accounts and authentication to an untrusted domain), then NTLM still rules!

Authentication

This topic could get huge, so let's restrict it to the modes of authentication supported by IIS. They are:

Anonymous - a token is created in IIS to represent all anonymous users with the same anonymous account. The default account is IUSR_NetBIOSNameOfMachine

Basic - credentials are then transmitted in unencrypted Base64-encoded format. This means that they will be sent in clear text. The only way to prevent this is to wrap the credentials using SSL. Since the server receives unencrypted credentials, it can then use them to impersonate the caller and use the same credentials to access network resources.

Integrated windows - uses either NTLM or Kerberos v5. Kerberos is used if the following criteria are met:

The application is using the network service or a domain account (otherwise NTLM used if the application is running under a local user account).

A SPN exists for the domain account used to run the service with which the client is authenticating.

Client and server are W2K+, and are in the same or trusting domain.

NTLM Authentication





Note in the above diagram, the challenge is just a 16 byte random number, so the client then just encrypts it with the password hash of the user and returns it. Then, in step 5, the DC obtains the password hash for the user and then uses it to encrypt the original challenge. If this matches the original response from the client then the DC sends the server confirmation that the user is authenticated.



Kerberos Authentication




Breaking this down further:

1. When a user attempts to log on to client, the kerberos service on the client sends a kerberos authentication request to the KDC. This request will contain user name, service information for which the TGT is requested, and a time stamp that is encrypted with the user password.
2. The DC will decrypt the timestamp with the user password that it gets from AD. If the timestamp is then valid, the user is genuine. The KDC will then create a logon session key, and encrypts the copy with the user password. The authentication service then creates a TGT which includes user info and the logon session key. The authentication service will then encrypt the TGT with its own key and passes both the encrypted session key and encrypted TGT to the client.
3. The client will then decrypt the logon session key using the user password and caches it locally. Also stores the encrypted TGT in its cache. When accessing a network service, the client will send a request to the KDC ticket granting service (TGS) with information that includes the user name, an authenticator message encrypted using the user's session key, the TGT and the name of the service that they want to access.
4. The TGS on the KDC decrypts the TGT using its own key and extracts the logon session key. Using this logon session key it can decrypt the authenticator message (which is usually a timestamp). If this authenticator message is successfully decrypted, the TGS extracts user info from the TGT, and using this user info will create a service session key for accessing the service. One copy of the service session key is encrypted with the user's logon session key, and a service ticket is then created with the service session key and the user info. The service ticket is then encrypted with the server's password. The TGS then sends the encrypted service session key and service ticket to the client.
5. When the client accesses the service, it sends a message to the server containing the authenticator message (timestamp) which is encrypted using the service session key and the service ticket.
6. The server decrypts the service ticket and extracts the service session key, which it then uses to decrypt the authenticator message. It evaluates this. If the authenticator passes the test, the server encrypts the authenticator message using the service session key and then passes the authenticator back to the client. The client decrypts it and if it is the same as the original the service is genuine and the client proceeds with the connection.

Advantages of kerberos

• Mutual authentication - so client is assured that the service is not being impersonated.
• Delegation support - servers that authenticate clients using kerberos can impersonate those clients and use their security context to access network resources.
• Better performance than NTLM.
• In multiple domains, point to point trust relationships are not required.

SPNs
These enable mutual authentication, and allow clients to request tickets to then communicate with a particular service.
SPNs in AD maintain a mapping between the constructed name e.g. MyService/MyServer:1879 and the domain account under which the service you want is running. For this to be impersonated, an attacker would need to disable the real service and remove the actual server from the network. They'd then need to add a new computer with the same name and expose the duplicated service. Since Kerberos v5 uses mutual authentication, the client will not be able to use the duplicated service unless it knows the password for the domain account under which the actual service is configured to run.

Old password still valid for an hour

Not sure why I haven't blogged this one before.

With Windows Server 2003 Sp1, MS decided to modify NTLM authentication behaviour (this also affects LDAP authentication) so that a user can use their old password for an hour to access the network after it has changed.
This is to allow things like service accounts to still be able to login while the new password propagates.
However, I've never been convinced that the case is there (why does kerberos not need it?).

To disable this feature, you need to modify HKLM\System\CurrentControlSet\Control\LSA\OldPasswordAllowedPeriod. This is a DWORD value.
Setting it to 0 means that you disable the use of old passwords.
If this value is not in the registry the default of 60 minutes is used.

See kb906305 for further details.