Entiendo que las bases de datos LDAP son más seguras, pero ¿siempre es necesario usar LDAP en lugar de MySQL para los nombres de usuario y las contraseñas?
No estoy seguro de estar de acuerdo en que "las bases de datos LDAP son más seguras". Después de todo, un servidor LDAP es básicamente un servidor de base de datos, con exactamente los mismos riesgos de seguridad. LDAP es agradable si tiene las necesidades (software que puede autenticarse contra LDAP, etc.) y herramientas, pero desde el punto de vista de la seguridad, no veo una diferencia entre usar LDAP y MySQL (dado que no hace estupideces como contraseñas de texto claro o hashes sin sal).
Principio de separación de privilegios
Este es un caso clásico donde el aislamiento de su base de datos de contenido de su base de datos de usuario proporciona una ventaja de seguridad.
El Servidor LDAP no es más seguro, pero tiene un propósito limitado y, por lo tanto, el área de superficie para el ataque es mucho menor, a diferencia de la tabla de usuario típica almacenada en una base de datos de contenido que puede ser recuperado directamente en el caso de un exploit de inyección.
El Servidor LDAP y la Base de datos de contenido están ocultos (en algunas arquitecturas) por el Servidor de aplicaciones , por lo que no se requiere acceso directo y solo es posible atravesar ataques, lo que reduce aún más la posibilidad de compromiso.
Estos servicios múltiples introducen una complejidad que tiene costos y problemas, pero constituyen un patrón que alienta / obliga al diseñador / desarrollador a mantener separadas estas responsabilidades / preocupaciones específicas en lugar de colapsar la implementación en un sistema inseguro.
Otra forma de verlo es que siempre se cometen errores al diseñar / desarrollar / implementar un sistema, y sin esta separación de responsabilidades, los errores cometidos en un dominio pueden sangrar y comprometer los otros dominios.
Nota: A través de una lectura rápida del protocolo LDAP , una contraseña es un campo en la base de datos LDAP, por lo tanto, si ese campo está marcado (la mejor práctica), entonces la base de datos LDAP no necesita conocer la contraseña de texto simple, y como comentarista señala que existen API especiales para evitar problemas con la contraseña autenticación.
Es discutible que LDAP sea más seguro que MySQL.
Realmente no veo los beneficios de agregar otro servicio complejo a una infraestructura. Si desea aislar la autenticación, no utilice una base de datos MySQL segura (SSL). Si desea una forma estandarizada de acceder a una base de datos de autenticación, ¿por qué no crear un esquema MySQL estándar?
LDAP es excelente cuando tiene que autenticar muchos servicios diferentes contra un único Backend (una contraseña para todos o incluso SingleSignOn) o cuando tiene diferentes lugares físicos dispersos en el mundo, tiene que autenticarse contra un único backend como LDAP es ideal para información de fragmentación.
Pero cuando eso no es un MustHave y solo está pensando en utilizar LDAP como servidor de autenticación, siempre votaría por minimizar los sistemas, lo que significaría que si necesita una base de datos para su aplicación, utilice esa base de datos también para la autenticación.
Como alternativa, consideraría usar OAuth o OpenID para que los usuarios puedan iniciar sesión con un servicio diferente y no tenga que considerar la opción de Hashing de contraseñas, ya que no almacena las contraseñas. De esa forma, delegaría la autenticación a un servicio externo.
El problema de las contraseñas cifradas es que la mayoría de las veces el usuario envía su contraseña sin cifrar (solo cifrada por una conexión https) al servidor. Desde allí, el servidor puede usar el cifrado o no para conectarse al LDAP. Pero cuando usa el comando de enlace predeterminado de LDAP, debe proporcionar la contraseña no cifrada al LDAP para que no haya beneficios. Por el contrario, cuando usa una base de datos, puede almacenar la contraseña cifrada en la base de datos y luego puede consultar la contraseña cifrada, de modo que, entre su aplicación y la base de datos, la contraseña solo se envíe cifrada. ¡Sin embargo, eso no cifra la contraseña entre el usuario y la aplicación!
O bien usarán una tecnología patentada que luego es irrelevante para usted, o usarán soluciones en el mercado. Lo que quizás sea importante en su pregunta es la escalabilidad de estas soluciones. Para el "Servidor LDAP" hay OpenLDAP que se puede configurar para usar MySQL como almacenamiento de fondo. Si necesitara escalabilidad, buscaría esta combinación. LDAP es muchas veces más rápido que SQL. LDAP no es una base de datos relacional. De hecho, no es una "base de datos" de propósito general, es un directorio con estructura de árbol.
Muchos de los conceptos con los que está familiarizado en las bases de datos relacionales no se aplican realmente a LDAP. Por ejemplo, no hay "tablas" y no hay operación de "unión".