NTLM

El servidor autentica al cliente enviándole un número aleatorio de 8 bytes, el desafío. El cliente realiza una operación en la que intervienen el desafío y un secreto compartido entre el cliente y el servidor, concretamente uno de los dos hashes de contraseña descritos anteriormente. El cliente devuelve el resultado de 24 bytes del cálculo. De hecho, en NTLMv1 los cálculos se realizan normalmente utilizando ambos hashes y se envían ambos resultados de 24 bytes. El servidor verifica que el cliente haya calculado el resultado correcto y, a partir de esto, deduce la posesión del secreto y, por tanto, la autenticidad del cliente.

Ambos hashes producen cantidades de 16 bytes. Se añaden cinco bytes de ceros para obtener 21 bytes. Los 21 bytes se separan en tres cantidades de 7 bytes (56 bits). Cada una de estas cantidades de 56 bits se utiliza como clave para cifrar con DES el desafío de 64 bits. Los tres encriptaciones del desafío se reúnen para formar la respuesta de 24 bytes. Tanto la respuesta que usa el hash LM como el hash NT se devuelven como respuesta, pero esto es configurable.

C = Desafío de servidor de 8 bytes, aleatorio
K1 | K2 | K3 = NTLM-Hash | 5-bytes-0
Respuesta = DES(K1,C) | DES(K2,C) | DES(K3,C)

NTLMv2, introducido en Windows NT 4.0 SP4 [14] (y soportado de forma nativa en Windows 2000), es un protocolo de autenticación desafío-respuesta. Está pensado como un sustituto reforzado criptográficamente de NTLMv1, que mejora la seguridad de NTLM endureciendo el protocolo contra muchos ataques de suplantación de identidad y añadiendo la posibilidad de que un servidor autentique al cliente.[1][15][16]

NTLMv2 envía dos respuestas a un desafío de servidor de 8 bytes. Cada respuesta contiene un hash HMAC - MD5 de 16 bytes del desafío del servidor, un desafío del cliente generado total o parcialmente de forma aleatoria y un hash HMAC-MD5 de la contraseña del usuario y otra información de identificación. Las dos respuestas difieren en el formato del desafío del cliente. La respuesta más corta utiliza un valor aleatorio de 8 bytes para este desafío. Para verificar la respuesta, el servidor debe recibir como parte de la respuesta el desafío del cliente. Para esta respuesta más corta, el desafío de cliente de 8 bytes añadido a la respuesta de 16 bytes forma un paquete de 24 bytes que es coherente con el formato de respuesta de 24 bytes del protocolo NTLMv1 anterior. En cierta documentación no oficial (p. ej. DCE/RPC sobre SMB, Leighton) esta respuesta se denomina LMv2.

La segunda respuesta enviada por NTLMv2 utiliza un desafío de cliente de longitud variable que incluye (1) la hora actual en formato NT Time, (2) un valor aleatorio de 8 bytes (CC2 en el cuadro de abajo), (3) el nombre de dominio y (4) algunas cosas de formato estándar. La respuesta debe incluir una copia de este desafío del cliente, por lo que es de longitud variable. En la documentación no oficial, esta respuesta se denomina NTv2.

Tanto LMv2 como NTv2 hacen un hash del desafío del cliente y el servidor con el hash NT de la contraseña del usuario y otra información de identificación. La fórmula consiste en comenzar con el hash NT, que se almacena en el SAM o AD, y continuar con el hash, utilizando HMAC - MD5, el nombre de usuario y el nombre de dominio. En el cuadro siguiente, X representa el contenido fijo de un campo de formato.

SC = desafío de servidor de 8 bytes, aleatorio
CC = desafío de servidor de 8 bytes, aleatorio
CC* = (X, tiempo, CC2, nombre de dominio)
v2-Hash = HMAC-MD5(NT-Hash, nombre de usuario, nombre de dominio)
LMv2 = HMAC-MD5(v2-Hash, SC, CC)
NTv2 = HMAC-MD5(v2-Hash, SC, CC*)
respuesta = LMv2 | CC | NTv2 | CC*

El protocolo de sesión NTLM2 es similar a MS-CHAPv2.[17] Consiste en la autenticación de NTLMv1 combinada con la seguridad de sesión de NTLMv2.

En resumen, se aplica el algoritmo NTLMv1, excepto que se agrega un desafío de cliente de 8 bytes al desafío de servidor de 8 bytes y se aplica un hash MD5. La mitad menos significativa de los 16 bytes del resultado del hash es el desafío utilizado en el protocolo NTLMv1. El desafío de cliente se devuelve en una espacio de 24 bytes en el mensaje de respuesta, mientras que la respuesta calculada de 24 bytes se devuelve en el otro espacio.

Se trata de una forma reforzada de NTLMv1 que mantiene la capacidad de utilizar la infraestructura del controlador de dominio existente, pero evita un ataque de diccionario por parte de un servidor fraudulento. Para una X fija, el servidor calcula una tabla donde la ubicación Y tiene un valor K tal que Y=DES_K(X) . Sin que el cliente participe en la elección del desafío, el servidor puede enviar X, buscar la respuesta Y en la tabla y obtener K. Este ataque se puede hacerse práctico utilizando tablas arco iris.[18]

Sin embargo, la infraestructura NTLMv1 existente permite que el par desafío/respuesta no sea verificado por el servidor, sino que lo envíe a un controlador de dominio para su verificación. Utilizando la sesión NTLM2, esta infraestructura sigue funcionando si el servidor sustituye el desafío por el hash de los desafíos del servidor y del cliente.

NTLMv1
 Cliente<-Servidor: SC
 Cliente->Servidor: H(P,SC)
 Servidor->DomCntl: H(P,SC), SC
 Servidor<-DomCntl: sí o no

NTLM2 Session
 Cliente<-Servidor: SC
 Cliente->Servidor: H(P,H'(SC,CC)), CC
 Servidor->DomCntl: H(P,H'(SC,CC)), H'(SC,CC)
 Servidor<-DomCntl: sí o no

El NTLM SSP se utiliza en las siguientes situaciones:

• El cliente se está autenticando en un servidor que no pertenece a un dominio o no existe ningún dominio de Active Directory (comúnmente conocido como "grupo de trabajo" o "punto a punto")
  • El servidor debe tener habilitada la función de "uso compartido protegido por contraseña", que no está habilitada de forma predeterminada y que es mutuamente excluyente con HomeGroup en algunas versiones de Windows.
  • Cuando el servidor y el cliente pertenecen al mismo grupo doméstico (HomeGroup), se utilizará un protocolo similar a Kerberos, llamado Autenticación Usuario a Usuario basada en Criptografía de Clave Pública, en lugar de NTLM.[22] HomeGroup es probablemente la forma más fácil de compartir recursos en una red pequeña y requiere una configuración mínima, incluso en comparación con la configuración de algunos usuarios adicionales para poder usar el uso compartido protegido por contraseña, lo que puede significar que se usa mucho más que el uso compartido protegido por contraseña en Redes pequeñas y redes domésticas.
• Si el servidor es un dispositivo compatible con SMB, como dispositivos NAS e impresoras de red, el SSP de NTLM puede ofrecer el único método de autenticación compatible. Algunas implementaciones de SMB o distribuciones anteriores de, por ejemplo Samba puede hacer que Windows negocie NTLMv1 o incluso LM para la autenticación de salida con el servidor SMB, lo que permite que el dispositivo funcione aunque puede estar cargado con software obsoleto e inseguro, independientemente de si se trata de un dispositivo nuevo.
• Si el servidor es miembro de un dominio pero no se puede utilizar Kerberos .
  • El cliente se está autenticando en un servidor usando una dirección IP (y no hay disponible una resolución de nombre inversa)
  • El cliente se está autenticando en un servidor que pertenece a un bosque de Active Directory diferente que tiene una confianza NTLM heredada en lugar de una confianza transitiva entre bosques.
  • Donde un firewall restringiría los puertos requeridos por Kerberos (típicamente TCP 88)

Después de que el desarrollador de la aplicación o el SSP de negociación hayan decidido que se use el SSP de NTLM para la autenticación, la directiva de grupo determina la capacidad de usar cada uno de los protocolos que implementa el SSP de NTLM. Hay cinco niveles de autenticación.[23]

• Enviar respuestas LM y NTLM : los clientes usan la autenticación LM y NTLM, y nunca usan la seguridad de sesión NTLMv2; Los DC aceptan autenticación LM, NTLM y NTLMv2.
• Enviar LM y NTLM: use la seguridad de sesión NTLMv2 si se negocia : los clientes usan la autenticación LM y NTLM, y usan la seguridad de sesión NTLMv2 si el servidor lo admite; Los DC aceptan autenticación LM, NTLM y NTLMv2.
• Enviar solo respuesta NTLM : los clientes solo usan autenticación NTLM y usan seguridad de sesión NTLMv2 si el servidor lo admite; Los DC aceptan autenticación LM, NTLM y NTLMv2.
• Enviar solo respuesta NTLMv2 : los clientes solo usan autenticación NTLMv2 y usan seguridad de sesión NTLMv2 si el servidor lo admite; Los DC aceptan autenticación LM, NTLM y NTLMv2.
• Enviar solo respuesta NTLMv2\rechazar LM : los clientes solo usan autenticación NTLMv2 y usan seguridad de sesión NTLMv2 si el servidor lo admite; Los DC rechazan LM (aceptan solo autenticación NTLM y NTLMv2).
• Enviar solo respuesta NTLMv2\rechazar LM y NTLM : los clientes solo usan autenticación NTLMv2 y usan seguridad de sesión NTLMv2 si el servidor lo admite; Los DC rechazan LM y NTLM (aceptan solo la autenticación NTLMv2).

DC significaría controlador de dominio, pero el uso de ese término es confuso. Cualquier computadora que actúe como servidor y autentique a un usuario cumple la función de DC en este contexto, por ejemplo, una computadora con Windows con una cuenta local como Administrador cuando esa cuenta se usa durante un inicio de sesión en la red.

Antes de Windows NT 4.0 Service Pack 4, el SSP negociaba NTLMv1 y recurría a LM si la otra máquina no lo admitía.

A partir de Windows NT 4.0 Service Pack 4, el SSP negociaría la sesión NTLMv2 siempre que tanto el cliente como el servidor la soportaran.[24] Hasta Windows XP inclusido, se utilizaba un cifrado de 40 o 56 bits en ordenadores no estadounidenses, ya que Estados Unidos tenía entonces severas restricciones a la exportación de tecnología de cifrado. A partir de Windows XP SP3, el cifrado de 128 bits podía añadirse instalando una actualización y, en Windows 7, el cifrado de 128 bits sería el predeterminado.

En Windows Vista y posteriores, LM se ha desactivado para la autenticación entrante. Los sistemas operativos basados en Windows NT hasta Windows Server 2003 inclusive almacenan dos hashes de contraseña, el hash de LAN Manager (LM) y el hash de Windows NT. A partir de Windows Vista, existe la posibilidad de almacenar ambos, pero uno está desactivado por defecto. Esto significa que la autenticación LM ya no funciona si el equipo que ejecuta Windows Vista actúa como servidor. Las versiones anteriores de Windows (hasta Windows NT 4.0 Service Pack 4) podían configurarse para comportarse de esta manera, pero no era el valor predeterminado.[25]