Se trata de cómo interpretas lo que están escribiendo. No están diciendo que no debas hash y debes almacenar las contraseñas en texto plano. Lo que está diciendo es que el valor que escribes en LDAP no está cifrado ni cifrado. Esto es como la situación que tiene con una base de datos normal. Puede definir una columna llamada contraseña y puede indicar a la base de datos que cifre esa columna o no. Luego puede pegar datos en esa columna, que puede estar encriptada / en hash o en texto sin formato. Si define la columna como cifrada, los datos se cifran a medida que se escriben en la columna y se descifran cuando se leen. Si está almacenando los hash de una contraseña, ese hash también estará cifrado y será necesario descifrarlo antes de poder utilizarlo. En general, el cifrado de la base de datos se trata de proteger los datos exportados en volcados de datos, etc. Es un poco como el cifrado de disco, ya que una vez que tiene acceso a las tablas de la base de datos, el cifrado / descifrado se realiza entre bastidores y no lo ve. Sin embargo, si alguien logra acceder a un volcado de datos o obtiene acceso al archivo de datos de la tabla en el disco, no podrá leer la información.
Tenga en cuenta la definición de atributos de contraseña como almacenados en una sintaxis de cadena de octeto. Este formato se define para admitir la gama completa de caracteres que encontrará en las contraseñas con hash. Lo que dice la mejor práctica es que LDAP almacena el valor que le das "tal como está" sin ningún tipo de cifrado o hash adicional. Es el deber del software el que administra estos datos hacer cualquier hashing que desee
La 'L' es LDAP significa ligero. Un servidor LDAP normalmente ve muchas lecturas con muchas menos escrituras. Está diseñado para manejar muchas consultas y trata de garantizar un buen rendimiento manteniéndolo simple. Agregar cifrado crea una sobrecarga innecesaria adicional. Si el atributo de contraseña estaba encriptado, entonces todas las consultas necesitarían descifrar esa información, degradando el rendimiento.
LDAP también mantiene las cosas simples al no proporcionar una interfaz de administración. Es esencialmente un árbol definido de atributos y valores cuya función principal es responder consultas. Para reforzar aún más esto, a menudo encontrará que en entornos de alta demanda, tendrá un servidor LDAP maestro donde se envían todas las escrituras / actualizaciones y servidores esclavos / replicables donde se envían todas las consultas. Cuando escribe al maestro, si va a reenviar los cambios a los esclavos.
El manejo de los datos generalmente se realiza por algún otro programa. Por ejemplo, en nuestro sitio, tenemos un programa perl que recibe datos de nuestro sistema IAM. Luego toma estos datos, aplica algunas reglas de negocios y escribe los resultados en el maestro LDAP. El programa perl realiza los hashes de las contraseñas (en realidad necesitamos admitir varios tipos de hash para cada contraseña porque no todas las aplicaciones entienden el mismo algoritmo de hash. Este hashing también agrega un salt.
Cuando un cliente consulta el servidor LDAP, solo obtendrá lo que esté almacenado en el atributo. Con las contraseñas, los datos almacenados incluyen detalles de qué tipo de hash se ha utilizado. Por supuesto, para que los enlaces funcionen, el servidor LDAP debe comprender al menos uno de los hash que se utilizan para realizar el enlace.
En nuestro caso, el hash principal que usamos es SHA-512. Las referencias a MD5, SHA1, Crypt, etc. están desactualizadas y no deben utilizarse. Este es otro ejemplo de la ventaja de este enfoque. Solíamos usar SHA-1 e incluso Crypt una vez. Podríamos actualizar fácilmente a un nuevo algoritmo de hashiing sin tener que preocuparnos demasiado por LDAP y las versiones, etc.