Hoy, cualquier organización tiene un directorio LDAP lleno de usuarios de esta organización. Si observa detenidamente, encontrará una o más aplicaciones que utilizan el mismo directorio para la "autenticación". Y las comillas no son accidentales aquí, porque LDAP es un protocolo de acceso a directorio diseñado para leer, escribir y buscar el servicio de directorio. Este no es un protocolo de autenticación. El término "autenticación LDAP", más bien, se refiere a esa parte del protocolo (operación de enlace), que determina quién es usted y qué derechos de acceso tiene a la información del directorio.
Con el tiempo, LDAP se ha convertido en un servicio de autenticación de facto. Los servicios LDAP extendidos y asequibles, como Active Directory, se han convertido en un tidbit para los desarrolladores de software que desean integrar la autenticación en sus productos. Las bibliotecas de cliente LDAP están disponibles para casi cualquier marco, y la integración es relativamente fácil de implementar.
Pero a pesar del hecho de que el uso de LDAP puede ayudar a resolver el problema de implementar la autenticación de usuario en varias aplicaciones de la compañía, crea muchos problemas. A diferencia de los protocolos de autenticación especialmente diseñados, el uso de LDAP causa varias vulnerabilidades de seguridad de la información.
Para comprender cuáles son estas vulnerabilidades, primero debe comprender cómo funciona la autenticación LDAP.
Cómo funciona la autenticación LDAP
Imagine la siguiente situación (está lejos de la realidad, pero transmite la esencia perfectamente).
Supongamos que hago un pedido en una tienda en línea para que se entregue a mi casa en mi ausencia. El mensajero llega y deja una nota debajo de la puerta con el texto "Lo siento, no te encontramos" y me pide que recoja el pedido en el punto de recogida más cercano en un momento conveniente. En el punto de recogida, el empleado me pide mi nombre, dirección y me pide las llaves de la casa para confirmar mi identidad. Entonces el oficial de servicio de entrega llega a mi casa y abre la puerta con mi llave. Él entra para asegurarse de que yo vivo allí, por ejemplo, de fotografías en la pared o por el nombre del destinatario en la correspondencia. Después de eso, el empleado regresa al punto de emisión y me informa que ha confirmado con éxito mi identidad, ¡y puedo recibir mi paquete! ¡Hurra!
Además de los problemas con la logística, esta situación está llena de otros problemas. ¿Qué sucede si un revisor sin escrúpulos hizo una copia de mi clave? ¿O dejó la llave durante mucho tiempo desatendida, y alguien más? ¿Qué pasa si el probador fue atacado y me quitaron la llave? Cuando le doy la llave de mi apartamento a un extraño, no puedo estar seguro de su decencia y mi seguridad.
Afortunadamente, en el mundo real tenemos documentos de identificación, por ejemplo, una licencia de conducir o un pasaporte, emitidos por agencias gubernamentales, y su autenticidad no está en duda. Puedo proporcionar estos documentos al servicio de mensajería para mi propia identificación sin entregar las llaves.
En el mundo LDAP, todavía tenemos que pasar nuestras llaves para abrir la puerta en nuestro nombre. Transferimos nuestra contraseña a un tercero, y él está tratando de penetrar en el servidor LDAP con ella. Si logra obtener acceso, no podemos estar seguros de que nuestras credenciales no se vean comprometidas. En este caso, el atacante obtendrá no solo la capacidad de desbloquear la puerta LDAP, sino también el acceso a cualquier aplicación que use las mismas credenciales.
Afortunadamente, en un mundo más completo de autenticación, ¡también tenemos pasaportes y licencias de conducir! Los protocolos de autenticación como Kerberos, SAML y OpenID Connect emiten tokens a terceros. Los tokens confirman que usted es quien dice ser, y no hay necesidad de transferir sus llaves a nadie. Debido a que LDAP nunca fue diseñado como un protocolo de autenticación, carece de los mecanismos apropiados.
Desventajas de LDAP como sistema de autenticación
En 2007, Shumon Hack lanzó un artículo de ciencia ficción (
LDAP Weaknesses as a Central Authentication System ) en el que describe tres problemas específicos cuando se utiliza LDAP como sistema de autenticación.
1. La aplicación probablemente no sea lo suficientemente segura como para manejar credenciales
El autor enfatiza que proteger un pequeño conjunto de servidores de autenticación de ataques es mucho más fácil que proteger una gran cantidad de servidores de aplicaciones.
En general, los servidores de autenticación, por regla general, están bajo la estrecha supervisión de especialistas con experiencia significativa en el campo de la seguridad de la información.
Por otro lado, los servidores de aplicaciones tienen un nivel de seguridad completamente diferente y están más expuestos a riesgos. Son menos seguros, funcionan con pilas de software más complejas y es más probable que tengan vulnerabilidades. Y más a menudo son administrados por personas que no tienen un profundo conocimiento de la seguridad. Construir el sistema de seguridad adecuado es un proceso complicado en el que es muy fácil cometer un error.
El problema es que si un servidor de aplicaciones se ve comprometido, todas las credenciales utilizadas por sus propietarios durante el ataque también se verán comprometidas. Cualquier otro sistema que use el mismo directorio LDAP para la autenticación está en riesgo.
2. El servidor LDAP no puede asegurar el mecanismo de autenticación utilizado para obtener credenciales
Un servidor LDAP no puede garantizar la seguridad de la transacción. Aunque un servidor LDAP, por ejemplo, puede forzar la vinculación a través de TLS para garantizar que las credenciales no se transmitan en texto claro, el servidor en sí nunca tuvo ningún papel en la obtención de credenciales del usuario. Existe el riesgo de que la aplicación reciba una contraseña a través de un canal inseguro.
3. El usuario se ve obligado a compartir su secreto de autenticación con un tercero.
La contraseña de usuario o el secreto de autenticación deben permanecer en
secreto . Debe ser conocido solo por el usuario y el sistema de autenticación. Al usar la autenticación LDAP, el usuario se ve obligado a compartir su secreto con un tercero para que luego pueda usar este secreto para interactuar con el directorio LDAP en nombre del usuario.
Es importante mencionar que cuando se utilizan protocolos de autenticación especialmente diseñados, como Kerberos, e incluso desde el NTLM anterior, el secreto del usuario nunca se transmite a través de la red. El dispositivo cliente y el servidor utilizan operaciones criptográficas para demostrar entre sí que tienen el mismo secreto y ni siquiera intercambian el secreto en sí.
A los puntos de Shumon Hook, agregaré una descripción de varios matices de autenticación LDAP, basada en mi propia experiencia. En primer lugar, el tema se refiere al uso de Active Directory.
4. Muchos desarrolladores no saben lo suficiente sobre los mecanismos LDAP para usarlo correctamente
Una de mis publicaciones de
blog anteriores describe cómo el enlace anónimo y no autenticado permitió burlar a los desarrolladores de aplicaciones y obligó a los usuarios no autorizados a omitir. La capacidad de realizar una operación de vinculación sin autenticación es una de las sutilezas del protocolo que incluso los expertos LDAP más experimentados desconocen.
Los directorios no son fáciles de organizar y son capaces de almacenar una gran cantidad de información organizacional y proporcionan muchas formas personalizables de almacenarla. Vi muchos casos en los que el desarrollador de la aplicación supuso que había una determinada clase de objeto o atributo, y cuando no se detectaron, la aplicación se bloqueó. Para la autenticación del usuario, no se debe requerir y aplicar el conocimiento de la estructura de los datos almacenados en el directorio. El protocolo de autenticación debe abstraerse de los detalles del repositorio de objetos ubicado en un nivel inferior.
5. Los administradores de aplicaciones a menudo no configuran clientes LDAP correctamente
Al administrar Active Directory en un gran entorno distribuido, hay un matiz desagradable: es difícil determinar qué aplicaciones específicas usan Active Directory como directorio LDAP y cómo los administradores de la aplicación configuraron exactamente el cliente LDAP.
Los siguientes son ejemplos de los horrores de la mala configuración.
- Codificación de DN en aplicaciones o uso de DN en una operación de enlace. Los problemas ocurren constantemente al cambiar el nombre o mover objetos dentro de un directorio, y todo porque alguien en algún lugar codificó DN. (Nota para aquellos que realizan operaciones de enlace simples con Active Directory: no es necesario usar un DN. Active Directory también proporciona formatos de DN alternativos que son más confiables que usar un formato tradicional).
- Para la operación de vinculación, no se utiliza una cuenta de servicio, sino una cuenta personal del desarrollador o administrador (imagine lo que sucederá cuando el propietario de la cuenta abandone la empresa).
- Envío de contraseñas en texto claro al puerto 389.
- Hay aplicaciones en las que no se requiere la casilla de verificación "Validar certificado" cuando se conecta a AD mediante TLS (puerto 636). ¿Por qué es esto generalmente aceptable? ¿Cómo puedo pasar la contraseña a un servicio de terceros sin estar convencido de su fiabilidad?
Hacer que el cliente LDAP funcione es fácil. Pero solo el hecho de que funcione no significa que la configuración sea correcta.
6. La autenticación LDAP y los servicios de autenticación modernos son mutuamente excluyentes
Una aplicación que utiliza LDAP para la autenticación siempre tendrá que depender de nombres de usuario y contraseñas. Intentar implementar tecnologías modernas, como la autenticación de múltiples factores y el inicio de sesión único, es casi imposible (a menos que vaya a implementar sus propias tecnologías, lo que en sí mismo es una mala idea). FIDO Alliance se compromete a hacer que las contraseñas sean una reliquia del pasado, y cada aplicación que use autenticación LDAP será un obstáculo para una política sin contraseña.
Cuales son las opciones?
Las aplicaciones web de hoy realmente pueden funcionar sin autenticación LDAP. Existen muchos protocolos excelentes de autenticación web, como SAML, WS-Federation y OpenID Connect, que no requieren credenciales de usuario para trabajar con aplicaciones de terceros. Innumerables productos proporcionan estos servicios, incluido el Servicio de federación de Active Directory (integrado en Windows Server) o servicios de terceros como Microsoft Azure AD, Okta, Ping y otros. Si su organización no tiene un IdP federado, lo primero que debe hacer es implementarlo.
Lo principal a lo que debe prestar atención al elegir un nuevo software es el soporte de los protocolos de autenticación modernos. Incluso si la empresa necesita la aplicación aquí y ahora, no se apresure a elegir una solución, especialmente si esta opción se limita solo a productos con autenticación LDAP. Vale la pena tratar de transmitir al proveedor seleccionado la necesidad de refinar el producto utilizando protocolos de autenticación más modernos. Quizás escuche y revise su plan de desarrollo.
La cantidad de aplicaciones de escritorio con un "cliente pesado" que admite protocolos de autenticación modernos está creciendo, y esta es una tendencia alegre. Estas aplicaciones solían ser una fortaleza de la autenticación LDAP. Un número creciente de SDK, como la Biblioteca de autenticación de Microsoft (MSAL), facilita a los desarrolladores agregar soporte para servicios de autenticación modernos a sus aplicaciones móviles y de escritorio.
En última instancia, vale la pena reconocer que en la realidad actual, no todas las aplicaciones admiten protocolos de autenticación modernos, y puede que nunca lo sean. La implementación de una prohibición completa de la autenticación LDAP probablemente no sea posible en ninguna organización. Sin embargo, de ninguna manera se debe fomentar la autenticación LDAP dentro de la organización. El uso de LDAP debe considerarse solo en ausencia de otras opciones.