¿Se debe evaluar la seguridad de la contraseña del usuario en el cliente o en el lado del servidor?

la fortaleza de la contraseña, en este contexto, es un concepto sin sentido. La fuerza de la contraseña, en la mayoría de los casos, no es una propiedad intrínseca de la contraseña en sí. Esa lógica de validación de entrada en los formularios de registro simplemente verifica la contraseña según ciertos criterios: ¿Tiene un número? ¿Tiene un carácter especial? ¿Es más largo que 8 caracteres? etc.

Estas comprobaciones se pueden realizar en el navegador del cliente o en el servidor. Sin embargo, la aplicación de esas condiciones solo se puede hacer en el servidor, ya que el usuario simplemente puede pasar por alto las restricciones del lado del cliente. Esos controles se realizan en el navegador del usuario porque es mucho más rápido hacerlo allí; Son solo indicadores para el usuario. Una vez que la contraseña se envía al servidor, debe verificarse en esas condiciones.

Nota al margen: no soy un gran fanático de las condiciones restrictivas de "seguridad de la contraseña" y no las recomiendo. Sin embargo, veo el beneficio de verificar la longitud mínima y asegurarme de que la contraseña no exista en un diccionario o lista de palabras.

Cualquiera de los dos es aceptable

Algunas consideraciones:

1. Desde el punto de vista de la usabilidad, la comprobación de del lado del cliente tiene menos latencia , y por lo tanto es más fácil de usar.

2. Puede hacer verificaciones más detalladas del lado del servidor . Por ejemplo, comprobando si la contraseña se basa en una palabra del diccionario. Sin embargo, la mayoría de los sitios No haga estos controles detallados. En cualquier caso, no estoy convencido de El beneficio de hacer verificaciones detalladas. El punto de comprobación de la contraseña. la fortaleza es solo para disuadir a alguien que usa una contraseña trivialmente débil, no más que eso.

3. Si realiza cualquier validación del lado del cliente, un usuario malintencionado puede Eludir los controles . Normalmente debe repetir cualquier comprobación en el servidor. Sin embargo, en el caso de la seguridad de la contraseña, no veo esto es importante. Si un usuario va a la longitud de utilizar un interactivo proxy para permitirse usar una contraseña débil, luego juego limpio para ellos. En ese momento, los dejaré en paz.

De hecho, en lugar de un comprobador de seguridad de contraseña, prefiero tener un asesor de seguridad de contraseña . Mientras el usuario escribe su contraseña, un indicador dice "débil ... medio ... fuerte". No se les prohíbe usar una contraseña débil; sólo están advertidos.

Editar en 2018 La mejor práctica ahora es verificar que la contraseña del usuario no sea uno de los millones que se han filtrado en violaciones de datos. Esto solo se puede hacer en el lado del servidor.

Una comprobación preliminar de Gmail indica que el análisis de seguridad de la contraseña se realiza en el lado del cliente mediante JavaScript. Leí su .js por un rato, decidí que era imposible de introducir a las 9:30 de la mañana sin café, y observé el cable con tcpdump mientras escribía una nueva contraseña. Cada pulsación de tecla no activaba el tráfico entre el navegador y Google, pero siempre que cambiaba la evaluación de la contraseña (por ejemplo, de "demasiado corta" a "débil"), el tráfico se correlacionaba con la pequeña burbuja de texto de ayuda.

Puedes presionar F12 en Chrome mientras estás en la página de cambio de contraseña y navegar todo su JavaScript. Toma café primero.

Dicho esto, en la World Wide Web las contraseñas se casi siempre se envían al servidor en texto sin formato, pero idealmente a través de HTTPS para que el reiniciador SSL proporcione seguridad. Están en texto sin formato en la forma GET o POST, o están codificados (no cifrados ) en el encabezado de Autenticación básica HTTP. ¿Por qué? Gestión de claves.

El cliente no tiene forma de cifrar la contraseña que comparte el servidor. Configurar uno requeriría distribuir claves secretas a clientes N + 1 y mantener el secreto ... o configurar un sistema de claves públicas. Y una vez que haya configurado un sistema de clave pública, solo debe patearse y decir "¿Por qué no confié en SSL para empezar?"

Ahora, aquí hay algunos valores atípicos a considerar:

Es posible que un servidor y un cliente realicen autenticación de resumen . En resumen, el servidor envía una cadena aleatoria, el cliente borra la contraseña, la combina con esa cadena aleatoria y la devuelve. El servidor debe tener una copia de texto simple de la contraseña correcta en su lado; Realiza el mismo proceso hash + mash y compara. Esto es más difícil para un atacante para agarrar la contraseña en el cable, pero generalmente requiere que el servidor conozca la contraseña de texto sin formato (a diferencia de una versión con hash).

BMC Remedy una vez implementó lo siguiente: La página de inicio de sesión contenía JavaScript que estafa la contraseña - IIRC almacenaba una estática cadena y realizaría un cifrado de sustitución en la contraseña utilizando esa cadena. Enviaría la cadena modificada al servidor, que simplemente podría revertir la sustitución. Único problema? Cualquiera podría revertir la sustitución, ya que seguía un algoritmo estático que se publicó en JavaScript en la página de inicio de sesión. Así que Remedy-over-HTTP no proporcionó una protección real para las contraseñas ... que se remonta a tema original, de "generalmente solo confiamos en SSL para proteger las contraseñas en tránsito"

Por último, tengo conocimiento de una aplicación, Litle PayPage , que distribuye JavaScript con una incrustada Llave pública. PayPage no acepta contraseñas sino datos de tarjetas de crédito, y JavaScript cifra el número de la tarjeta con esa clave incorporada antes envolviendo toda la solicitud en SSL y enviándola a través de HTTPS. Lo mismo se podría hacer con cualquier aplicación, esencialmente resolviendo el problema inicial que mencioné al compartir claves con el cliente, o reproduciendo el sistema SSL, elija su opción. La ventaja de este enfoque es que evita el problema tradicional de "¿Qué pasa si hay puertas de enlace HTTP que realizan un MITM en SSL?"

  

¿Debe evaluarse la seguridad de la contraseña del usuario en el cliente o en el lado del servidor?

Ambos.

La verificación del lado del cliente es muy útil desde una perspectiva de usabilidad, ya que puede realizarla sin que el usuario envíe datos al servidor, lo que incurrirá en una penalización de latencia. Dicha verificación se logra fácilmente usando javascript en un navegador web.

Si necesita la política de seguridad de la contraseña que debe aplicarse, tal vez como parte de un reglamento u otro, la aplicación debe realizarse en el lado del servidor. Cualquier comprobación del lado del cliente puede ser (relativamente) trivialmente anulada.