NTLM vs Kerberos vs LDAP: cuál elegir para tu e-commerce

En pocas palabras: Para un e-commerce con Active Directory, Kerberos es la opción más segura: cifra con AES, usa tickets con vida limitada y ofrece autenticación mutua. NTLM, con hashes MD4/MD5, quedó relegado a sistemas legacy tras el anuncio de retiro gradual de Microsoft en octubre de 2023.

NTLM vs Kerberos vs LDAP es la comparación que define cómo un e-commerce autentica usuarios y protege pedidos, pagos y perfiles de clientes. NTLM usa desafío-respuesta con hashes MD4/MD5, Kerberos emite tickets cifrados con AES a través de un Key Distribution Center, y LDAP consulta atributos de directorio en Active Directory. Microsoft ya anunció el retiro gradual de NTLM.

Conviene aclarar algo antes de meterse en los detalles técnicos: NTLM y Kerberos compiten entre sí porque los dos autentican identidades, pero LDAP juega en otra liga. No es un rival de los otros dos, es el que administra los datos de esos usuarios una vez que ya quedaron autenticados. Esa distinción, que suele perderse en las comparaciones rápidas, es la que ordena todo lo demás.

¿Qué es NTLM y por qué Microsoft lo sigue manteniendo en sistemas legacy?

NTLM (NT LAN Manager) es un protocolo de autenticación que Microsoft desarrolló para verificar identidades sin mandar la contraseña en texto plano por la red. En vez de eso, usa un hash de la contraseña dentro de un esquema de desafío-respuesta: el cliente pide acceso, el servidor le devuelve un número aleatorio de 16 bytes distinto en cada sesión, el cliente cifra ese número con el hash de su contraseña y lo manda de vuelta, y el servidor compara esa respuesta contra la que él mismo calculó con el hash guardado en la base SAM. Si coinciden, autentica. Todo el intercambio ocurre sin cifrado, lo cual explica buena parte de sus problemas de seguridad.

Sigue instalado en Windows porque miles de aplicaciones legacy y redes internas todavía dependen de él, aunque Microsoft ya marcó el camino hacia su retiro. Más contexto en comparativa completa entre Microsoft y GitHub.

NTLMv1, de 1993, usa cifrado de 56 bits y es vulnerable a ataques man-in-the-middle porque el cliente no puede verificar la identidad del servidor, según detalla el análisis de Netwrix. NTLMv2 subió a 128 bits y sumó timestamps del lado del cliente, pero Microsoft anunció en octubre de 2023 que iba a deprecar todas las versiones de NTLM.

¿Por qué no lo sacan de una vez? Porque romper compatibilidad con sistemas viejos sale caro, y ninguna empresa quiere ser la que rompe el ERP en producción por una migración apurada.

¿Cómo funciona el proceso de autenticación de Kerberos paso a paso?

Kerberos funciona con un Key Distribution Center (KDC) que emite tickets cifrados en vez de mandar contraseñas por la red. El KDC se divide en dos partes: el Authentication Server (AS), que valida el login inicial, y el Ticket Granting Server (TGS), que entrega los tickets de servicio. El nombre viene de Cerbero, el perro de tres cabezas de la mitología griega, según cuenta Netwrix (sí, en serio).

En la práctica, el flujo es este: el usuario hace login una sola vez y el cliente manda una Authentication Service Request (AS-REQ) al KDC con sus credenciales. El AS responde con un Ticket Granting Ticket (TGT) cifrado con la clave secreta del KDC, válido típicamente 10 horas. Cada vez que ese usuario necesita entrar a un recurso distinto, presenta el TGT al TGS, que le entrega un ticket de servicio cifrado con la clave secreta puntual de ese recurso. El usuario presenta ese ticket al servicio, que lo valida y da acceso sin volver a pedir la contraseña. Mientras la sesión esté viva, la contraseña nunca vuelve a viajar por la red.

Kerberos corre sobre el puerto 88 y usa cifrado AES en vez de los hashes MD4 que arrastra NTLM. Además hace autenticación mutua: el cliente valida al servidor y el servidor al cliente, algo que NTLM nunca hizo. Eso cambia todo, porque elimina de raíz los ataques man-in-the-middle que sí son posibles con NTLMv1.

¿Qué es LDAP y en qué se diferencia de un protocolo de autenticación?

LDAP (Lightweight Directory Access Protocol) es un protocolo para consultar y administrar objetos dentro de un directorio, como usuarios, grupos y permisos que viven en Active Directory. No es, por sí solo, un mecanismo de autenticación cifrado: un “simple bind” de LDAP puede mandar la contraseña en texto plano si no se agregan capas adicionales de cifrado. Te puede servir nuestra cobertura de conectarte por SSH a una VM de Azure.

La confusión típica es meter a LDAP en la misma bolsa que NTLM y Kerberos, como si compitieran entre sí. No compiten. LDAP resuelve “¿quién es este usuario y qué permisos tiene?”, mientras que Kerberos resuelve “¿es quién dice ser?”. Son capas distintas del mismo sistema, y tratarlas como alternativas intercambiables es el error de fondo detrás de varias configuraciones mal hechas.

Ojo con esto: un LDAP sin TLS es una fuga de credenciales esperando pasar.

¿Cuáles son las vulnerabilidades más comunes de NTLM?

Las tres vulnerabilidades más citadas de NTLM son los ataques pass-the-hash, los ataques de replay y el cracking por fuerza bruta o diccionario contra los hashes capturados. Las tres existen por la misma razón de fondo: NTLM nunca cifra el intercambio completo y depende de hashes que, una vez robados, sirven para autenticarse sin conocer la contraseña real.

En un pass-the-hash, el atacante captura el hash de la contraseña y lo reutiliza directamente, sin necesidad de descifrarlo. En un replay attack, como NTLM no valida sesiones ni cifra el intercambio, alguien puede interceptar una autenticación válida entre un empleado y un servidor y reenviarla para hacerse pasar por él, accediendo a pedidos y perfiles de clientes. Y en un ataque de fuerza bruta o diccionario, si el atacante consigue los hashes desde una base comprometida, corre software que prueba millones de combinaciones de contraseñas comunes hasta encontrar la que genera ese hash.

¿Alguien audita esto en la mayoría de las pymes? Rara vez. Y ahí está el problema real: no es que NTLM sea indefendible en todos los casos, es que casi nadie revisa si las condiciones que lo justifican siguen siendo válidas.

Criterios de decisión: cómo elegir sin copiar una tabla

Más allá de la comparación técnica, la elección real depende de tres preguntas concretas que conviene hacerse antes de mirar cualquier tabla de protocolos.

La primera es si el sistema tiene salida a internet. Un servicio interno, aislado, sin acceso externo, tolera NTLM con un riesgo acotado porque la superficie de ataque es limitada a quien ya está dentro de la red. Un panel de administración de pedidos o un checkout expuesto públicamente no debería depender de NTLM bajo ninguna circunstancia, porque ahí el riesgo de interceptación deja de ser hipotético.

La segunda es si ya existe una infraestructura de Active Directory funcionando. Si el e-commerce ya tiene un dominio AD, migrar a Kerberos no implica levantar infraestructura nueva, así que la resistencia a hacerlo suele ser más cultural que técnica. Si no hay AD y se trata de un equipo chico sin recursos de IT dedicados, NTLM como respaldo temporal es una decisión razonable, siempre que se documente como transitoria y no como definitiva.

La tercera es qué tan sensible es el dato que protege esa autenticación. Datos de pago, historial de compras o información personal de clientes justifican el costo de configurar Kerberos y LDAPS bien, incluso si eso implica una migración más lenta. Un sistema interno de stock que no toca datos de clientes tolera un estándar más bajo.

Protocolo	Mecanismo	Cifrado	Autenticación mutua	Uso recomendado en e-commerce
NTLM	Desafío-respuesta con hash	MD4/MD5, sin cifrar en tránsito	No	Redes internas aisladas o sistemas legacy
Kerberos	Tickets emitidos por un KDC	AES	Sí	Login de empleados y sistemas críticos
LDAP	Consulta y gestión de directorio	Depende (LDAPS o SASL)	No aplica	Gestión de permisos y perfiles de usuario

El propio análisis de securedbyprem en dev.to plantea el mismo dilema para startups: recursos limitados versus seguridad real. La conclusión no cambia: Kerberos gana cuando hay datos sensibles de por medio, pero la pregunta de fondo no es cuál protocolo es “mejor” en abstracto, sino qué combinación de los tres responde a las tres preguntas de arriba.

¿Se pueden combinar Kerberos y LDAP en un mismo sistema?

Sí, y es el esquema estándar en cualquier dominio de Active Directory. Kerberos autentica al usuario y le emite un ticket; una vez autenticado, LDAP consulta sus atributos (grupos, permisos, unidad organizativa) para decidir qué puede hacer dentro del sistema.

Ejemplo hipotético: pensemos en un empleado de logística de un e-commerce que hace login por la mañana. Kerberos valida sus credenciales y le entrega un TGT. Cuando ese empleado abre el panel de gestión de pedidos, LDAP consulta contra Active Directory si pertenece al grupo “Logística-Pedidos” antes de mostrarle la información. Si el mismo empleado intentara entrar al panel de facturación, sin pertenecer al grupo correspondiente, Kerberos lo seguiría reconociendo como usuario válido, pero LDAP le negaría el acceso a esa sección puntual. Ahí se ve la división de tareas: uno confirma la identidad, el otro decide el alcance.

Si tu e-commerce corre sobre un VPS o servidor dedicado, fijate que el proveedor te dé el control necesario para levantar un dominio Active Directory. En Argentina, proveedores como donweb.com ofrecen planes de VPS y servidores dedicados que podés usar como base para este tipo de infraestructura.

¿Cuándo tiene sentido seguir usando NTLM en una empresa?

NTLM tiene sentido en tres escenarios puntuales, y en ninguno de los tres funciona como base de la arquitectura sino como excepción acotada. El primero son las redes internas sin salida externa, donde es fácil de desplegar y compatible con sistemas viejos, ideal donde la prioridad es mantener equipos legacy funcionando sin superficie de ataque externa. El segundo es la administración interna de back office, en sistemas aislados de la red pública donde el riesgo de interceptación es bajo. El tercero es la autenticación VPN transitoria de empleados remotos, mientras se planifica la migración a Kerberos, nunca como solución permanente.

Fuera de esos tres casos, mantener NTLM activo es exponerse sin necesidad. Ya lo cubrimos antes en repos de GitHub comprometidos con malware.

Errores comunes al elegir entre NTLM, Kerberos y LDAP

El más frecuente es dejar NTLM habilitado “por las dudas”: muchas empresas nunca desactivan el fallback NTLM ni siquiera cuando ya migraron todo a Kerberos, y eso deja la puerta abierta a downgrade attacks. Muy cerca le sigue configurar LDAP sin LDAPS, usando un simple bind sin TLS que manda contraseñas en texto plano por la red, el mismo error que NTLM intentaba evitar hace treinta años.

Un tercer error, más conceptual, es pensar que Kerberos resuelve todo solo: autentica, pero no decide permisos, y sin LDAP bien configurado un usuario autenticado puede terminar viendo datos que no le corresponden. Y el último, quizás el más silencioso, es no auditar los logs de autenticación. El Event ID 4776 marca NTLM y el 4768 marca Kerberos en el Visor de eventos de Windows; si nadie los revisa, un ataque pass-the-hash puede pasar semanas sin detectarse.

Preguntas Frecuentes

¿Qué diferencia hay entre NTLM, Kerberos y LDAP?

NTLM autentica con hashes y desafío-respuesta sin cifrar el tránsito. Kerberos autentica con tickets cifrados con AES emitidos por un KDC. LDAP no autentica: consulta y administra los datos de usuarios dentro de un directorio como Active Directory.

¿Cuál es el protocolo de autenticación más seguro para un e-commerce?

Kerberos es el más seguro de los dos protocolos de autenticación porque cifra con AES, valida al cliente y al servidor entre sí, y nunca manda la contraseña por la red. Para un e-commerce, la combinación con LDAP sobre Active Directory cubre tanto el login como la gestión de permisos.

¿Por qué NTLM sigue siendo vulnerable a ataques pass-the-hash?

Porque NTLM autentica con el hash de la contraseña en vez de la contraseña misma, y ese hash no cambia entre sesiones salvo que se actualice la clave. Un atacante que capture ese hash puede reutilizarlo para autenticarse sin necesidad de descifrarlo ni de conocer la contraseña real.

¿Cómo funciona el Key Distribution Center (KDC) en Kerberos?

El KDC se divide en dos componentes: el Authentication Server (AS), que valida el login inicial y entrega un Ticket Granting Ticket, y el Ticket Granting Server (TGS), que usa ese TGT para emitir tickets de servicio específicos cada vez que el usuario necesita acceder a un recurso.

¿LDAP y Kerberos se pueden usar juntos o son excluyentes?

Se usan juntos, no son excluyentes. En un dominio de Active Directory, Kerberos autentica al usuario y LDAP consulta sus atributos y permisos una vez que esa autenticación ya se validó.

Conclusión

La comparación NTLM vs Kerberos vs LDAP no tiene un ganador universal, tiene un ganador según el contexto. Para un e-commerce que procesa pagos y guarda datos de clientes, Kerberos con AES y autenticación mutua debería ser la base, LDAP el que administra permisos, y NTLM el que queda guardado para casos puntuales y bien acotados. Las tres preguntas de arriba —¿hay salida a internet?, ¿ya existe AD?, ¿qué tan sensible es el dato?— sirven más que cualquier tabla para decidir rápido. Microsoft ya marcó la dirección: anunció en octubre de 2023 el camino hacia deprecar NTLM por completo, así que migrar no es una opción a futuro, es una tarea pendiente de ahora. Si todavía tenés sistemas corriendo NTLM sin saber bien por qué, ese es el primer lugar para mirar esta semana.

Fuentes

• SecuredByPrem en dev.to – NTLM vs Kerberos vs LDAP: Best Authentication for E-commerce
• Netwrix – Understanding NTLM and Kerberos: Key Differences and Use Cases
• Medium – Kerberos vs NTLM vs LDAP: Best Auth for E-commerce