¿Deberíamos verificar las restricciones de contraseña en los formularios de inicio de sesión?

Lo recomendaría en contra. Si desea protegerse de los ataques de inyección, hay otras formas, fundamentalmente mejores (por ejemplo, declaraciones preparadas para la inyección de SQL o el escape correcto para otros canales), además de la contraseña potencialmente maliciosa probablemente pasará sus filtros de restricción de todos modos (después de todo, es probable que aplique mínimo , no la longitud máxima de la contraseña, permita el "carácter, etc.)

Como dijo Tom Leek, agrega complejidad innecesaria. Si desea imponer un cambio de contraseña debido a las nuevas restricciones que están teniendo lugar, debe hacerlo después de la autenticación de todos modos, por lo que podría almacenar el indicador 'la contraseña ya no es buena' en la sesión, pero la verificación de validez debería ser una adición a la autenticación Procesar y no hacer antes de enviar la contraseña a LDAP.

La verificación de una contraseña ya registrada es útil SI las reglas que desea aplicar han cambiado Y TIENE la posibilidad de hacer que el usuario cambie su contraseña para que la nueva cumpla con las nuevas reglas. De lo contrario, es una pérdida de tiempo y una mayor complejidad (la complejidad es mala).

  

en caso de que estemos interceptando la contraseña que el usuario ha proporcionado y la comparemos con nuestras restricciones originales, el usuario debía seguirla al crear la contraseña antes de enviarla a LDAP para su autenticación.

¿Con qué fin? Esta es una característica más para equivocarse y filtrar información. ¿Cuántos beneficios puede proporcionar esta característica de cuánto cuesta hacer lo correcto, solucionar errores y lidiar con problemas imprevistos que bloquean a los clientes?

Bueno, estoy de acuerdo con los comentaristas, que una característica que no implementas no puede salir mal. Si deja que su servidor LDAP maneje la verificación de la calidad de la contraseña, tiene un solo lugar para configurarlo y está seguro de que se aplica.

Sin embargo, hay dos cosas a considerar, en primer lugar, desde el punto de vista de la experiencia del usuario, es bueno si el formulario de contraseña (AJAX) realmente da una respuesta directa si la contraseña está bien o no. Por lo tanto, siempre implementaría algunas verificaciones triviales para tener solo este comentario (indicador de fortaleza de la contraseña con un nivel mínimo antes de que pueda enviarlo).

Y, en segundo lugar, si tiene una aplicación que depende de una infraestructura compartida, las capacidades del servidor de directorio existente podrían no permitir el nivel de las comprobaciones que desea realizar (por ejemplo, ejecutar extensas ejecuciones de cracklib en un diccionario grande). O podría ser el caso de que los administradores del directorio no quieran / puedan considerar su caso de uso. En tal caso, es posible que el directorio no tenga controles lo suficientemente fuertes.

Buena noticia: si implementa sus propios controles y el directorio tiene los suyos propios, y dado que realmente utiliza un protocolo correcto para establecer una nueva contraseña (es decir, configurarlo como usuario objetivo y no como administrador), puede ser Asegúrese de que el más fuerte de ambos controles siempre lo rechazará, por lo que no puede debilitar la defensa.

Yo diría que si programa un software COTS que debería usarse en un contexto diferente, ofrezca algunas políticas para restringir. Si se encuentra en un entorno específico, es posible que se salga con el estilo básico de los controles de UI.

Nota: no estoy discutiendo la idea de las políticas de contraseñas aquí, hay pros y contras. Es muy importante que trate de no restringir en absoluto la complejidad máxima (conjunto de caracteres y longitud). Esta no es solo una característica de seguridad sino también su capacidad de uso (acepte contraseñas generadas automáticamente que son comunes con las cajas de seguridad de contraseñas).

  

La contraseña no se puede crear a menos que se cumplan todas las restricciones.

Se recomiendan las restricciones que mencionaste. Sólo para recapitular.

• Longitud mínima de la contraseña
• caracteres permitidos
• Ambos números y letras
• Caso mínimo de mezcla de caracteres alfa

  

¿Deberíamos estar interceptando la contraseña que el usuario ha proporcionado y compararla con nuestras restricciones originales que el usuario debía seguir al crear la contraseña antes de enviarla a LDAP para la autenticación [?]

     

¿Qué camino es mejor? ¿Por qué?

En la primera pregunta que implicó (pero no declaró explícitamente) que retendría las restricciones de creación de la entrada LDAP original (arriba) y luego preguntó: "¿De qué manera?" Creo que la segunda pregunta puede haber confundido a las personas que intentan responder bien. Asumiré que su departamento NO está pensando en REEMPLAZAR el cheque original sino en duplicarlo antes en el flujo de datos entre el teclado y la búsqueda LDAP.

  

No hay razón para verificar lo que el usuario proporciona como contraseña para iniciar sesión después de que ya la haya creado.

No por seguridad. El secreto en el LDAP no representa un riesgo mayor ni menor a largo plazo si las restricciones se verifican antes. Además, no está aumentando o disminuyendo la fuerza de la seguridad LDAP al verificar antes. Todas las probabilidades a largo plazo están intactas.

Note que seguí diciendo: "A largo plazo". La velocidad de un ataque de fuerza bruta se puede aumentar agregando un cheque adicional porque las respuestas negativas pueden regresar más rápidamente con un chequeo anterior. El espacio de permutación válido (conjunto de restricciones) podría ser determinado más rápidamente por un atacante inteligente si la respuesta negativa devuelve más rápidamente.

Por otro lado, los atacantes pueden tener mucho tiempo de todos modos. Además, su departamento podría agregar un retraso de respuesta de falla de restricción si lo eligieran.

  

Otras personas en mi departamento sienten que esas restricciones deben revisarse nuevamente antes de enviar la combinación de nombre de usuario / contraseña para autenticar.

Al lado de las otras personas por un momento, puede haber valor para el usuario si las entradas de contraseña mal escritas se detectan antes. A nadie le gusta esperar 10 segundos durante el alto volumen solo para descubrir que se presionó una tecla incorrecta no especificada.

Puede haber valor para la red, el servidor LDAP y niveles más bajos en el sistema durante los períodos de alta carga si se detectaron errores de forma anterior. Dudo que la mejora sea lo suficientemente significativa como para justificar la adición.

Personalmente, no agregaría la verificación adicional porque creo que es más probable que reduzca la seguridad en lugar de aumentarla, y agrega una operación de mantenimiento. Cada vez que se cambian las restricciones en el servidor LDAP, las restricciones deberían cambiarse en la verificación anterior. Agregar un poco de automatización para evitar esa necesidad sería otro componente del sistema que debería mantenerse. No es una gran idea.

No hay una necesidad imperiosa de argumentar en contra de la adición si se está formando un consenso en el departamento proporcionado

• Las restricciones LDAP originales se dejan en su lugar,

• El conjunto de restricciones de contraseña es lo suficientemente conservador como para que los ataques de fuerza bruta no sean realistas incluso si el atacante se entera de las restricciones,

• Y no tiene la responsabilidad personal de mantener la nueva verificación de restricciones funcionando y perfectamente alineado con las restricciones del servidor LDAP.