Protocolo de autenticación SASL sin contraseñas sin texto claro

Navega tus respuestas
3

Como ya sabe, LDAP admite tres mecanismos de autenticación : anónimo, simple y SASL.

El primero solo es adecuado para casos particulares, y por lo tanto no voy a hablar de eso. El segundo envía la contraseña sin cifrar y, por lo tanto, no es adecuada si no está dispuesto a implementarla sobre algo como SSL (debido a problemas de compatibilidad o razones legales).

Esto nos deja con la tercera opción: SASL. Como se indica en IANA , hay varios mecanismos de autenticación basados en SASL para elegir. Algunos de ellos son obsoletos o de uso limitado, pero otros son comunes.

Quiero elegir un mecanismo de autenticación basado en SASL, con las siguientes características:

  1. Se basa en una contraseña (en contraste con, por ejemplo, SecurID, que AFAIK se basa en token).
  2. Su seguridad no se basa en un protocolo subyacente (por ejemplo, SSL).
  3. El protocolo no requiere que las contraseñas de los usuarios se almacenen en forma clara (por ejemplo, CRAM-MD5 puede hacer esto ).
  4. Se implementa ampliamente.

¿Podría sugerir mis opciones?

    
pregunta M.S. Dousti 11.07.2012 - 22:14
fuente

2 respuestas

3

Hay dos mecanismos utilizados para autenticar una sesión LDAP:

  • simple
  • SASL

El mecanismo BIND simple toma una de cuatro formas:

  • anonymous - nombre nulo, credenciales nulas. Este es el estado inicial de una sesión.
  • unauthenticated - nombre no nulo, credenciales nulas. Los servidores de directorio deben configurarse para rechazar esta solicitud porque no se realiza ninguna autenticación.
  • name/password - nombre, credenciales
  • undefined - nombre nulo, credenciales no nulas. El comportamiento del servidor no está definido por los estándares LDAP. Los servidores de directorio deben configurarse para rechazar esta solicitud porque no se realiza ninguna autenticación.

Cuando un cliente LDAP se conecta al servidor de directorio, esa conexión tiene un estado de autenticación anónimo. El cliente puede solicitar que se cambie el estado utilizando la solicitud BIND. BIND también puede "restablecer" el estado de autenticación a anónimo.

El método de autenticación recomendado es BIND simple usando una conexión segura (SSL) o una conexión no segura promovida a una conexión segura usando la operación extendida StartTLS. Los servidores de directorios modernos y de calidad profesional admiten fuertes hash criptográficos de contraseñas con sal para dificultar la construcción de diccionarios.

Otro método es el mecanismo SASL GSSAPI , que evita la transmisión total de la contraseña.

Otro método es el mecanismo SASL EXTERNAL , que utiliza información no proporcionada por LDAP, por ejemplo, el certificado de cliente presentado durante el establecimiento de la sesión segura.

Otro método es el mecanismo SASL DIGEST-MD5 que evita la transmisión de la contraseña, pero tiene la desventaja de que el servidor debe tener acceso a la contraseña de texto sin cifrar o poder descifrar la contraseña del usuario, lo que significa usar un reversible esquema de almacenamiento de contraseña. DIGEST-MD5 debe evitarse por este motivo. Si se requiere DIGEST-MD5 , AES podría ser el mejor cifrado de bloque.

CRAM-MD5 es más débil que DIGEST-MD5 , y debe evitarse.

ver también

respondido por el Terry Gardner 12.07.2012 - 13:19
fuente
0

Realmente no tienes una opción, me temo.

SCRAM hace lo que usted desea, pero no se implementa ampliamente y, como ha visto, CRAM-MD5 es bastante débil.

    
respondido por el JasperWallace 14.02.2013 - 04:20
fuente

Lea otras preguntas en las etiquetas

¿Cómo diseñar SIEM RFP, teniendo en cuenta los grandes requisitos de la base de datos? Applet de Java para autenticación mutua con tarjeta inteligente