¿Por qué no se considera segura la verificación de la complejidad de la contraseña del lado del cliente? [duplicar]

Supones que la verificación se omite a propósito. Podría darse el caso de que alguien esté utilizando un navegador que no maneja el script correctamente o con los scripts deshabilitados, posiblemente incluso sin saberlo.

Parece que tienes una razón para que las personas usen contraseñas seguras. Si lo haces, ¿por qué aceptar que las personas pueden evitarlo?

La validación del lado del cliente puede ser útil desde una perspectiva de usabilidad, pero si decide que se requiere una contraseña mínima, debe hacerla cumplir implementándola en el lado del servidor.

La regla al escribir una aplicación de servidor es simplemente nunca confíes en lo que viene del cliente . Los chequeos realizados en el lado del cliente son excelentes, ya que permiten una experiencia agradable para el usuario con ventanas emergentes y una visualización inmediata. Pero como puede suceder cualquier cosa, desde un navegador javascript deshabilitado hasta un usuario que usa un lenguaje de scripting para simular un navegador, todas las comprobaciones deben hacerse (de nuevo) en el servidor.

Si solo se recomiendan contraseñas seguras, haga lo que quiera, si son un requisito, debe implementar el lado del servidor de verificación.

BTW: usted como desarrollador puede proponer soluciones, pero el cliente sí expresa sus requisitos. Si no está de acuerdo con ellos, puede solicitar una aclaración y proponer otras formas, pero al final el cliente decidirá.

Si el usuario DEBE establecer una contraseña segura, verificar la seguridad de la contraseña solo en el lado del cliente es una vulnerabilidad.

Ejemplo

Si trabaja en una empresa grande y tiene que cambiar su contraseña cada 2 o 3 meses, algunas personas comenzarán a pasar por alto la verificación de la fortaleza de la contraseña del lado del cliente para usarla más corta o mejor para memorizar las contraseñas. Si estas contraseñas se utilizan para derivar claves criptográficas, por ejemplo. para el cifrado multiusuario de archivos, se vuelve horrible ...

Solución

Compruebe siempre la seguridad de la contraseña en el servidor y, opcionalmente, compruebe la seguridad de la contraseña en el cliente para disminuir las solicitudes al servidor.

Biblioteca recomendada: ZXCVBN

• Utiliza la coincidencia de patrones y busca las contraseñas más utilizadas para estimar la fortaleza de la contraseña.
• Está disponible en múltiples lenguajes de programación

Sobre la base de la respuesta de Teun Vink , allí Hay algunos escenarios reales en los que un usuario puede omitir accidentalmente el control de seguridad.

Digamos que un usuario descarga un bloqueador de anuncios como Adblock Plus o uBlock Origin . Luego, debido a que los scripts están mal configurados, uno de estos bloqueadores bloquea accidentalmente el script que estaba usando para verificar la seguridad de la contraseña. Ahora el usuario puede ingresar 1234 como contraseña sin ninguna verificación del lado del servidor para evitarlo.

O alternativamente, el almacenamiento en caché local le dio al usuario una versión anterior de su script. Tal vez hayan guardado su página web como un archivo HTML estático en su escritorio. Tal vez la PC del usuario tenga un virus que alteró el contenido de su script. Como dice el dicho común ...

  

Nunca confíes en el usuario.

Editar: Ver también " No se puede guardar el perfil cuando maps.googleapis.com está bloqueado "para un gran ejemplo de por qué nunca debes confiar en el usuario.

Usted menciona que tanto el cheque como el amp; la habilitación del botón de envío es un script, por lo que es seguro incluso si algunos scripts están cargados y otros no. ¿Qué tan seguro está de que esas dos funciones siempre estarán en el mismo script?

Supongo que lo que estoy diciendo es que parece que, tal como están las cosas en este momento, significaría que alguien intencionalmente está haciendo algo que saben que es una mala idea para que puedan obtener una contraseña incorrecta, y estás bien. con ese; estás intentando prevenir accidentes, no estupideces intencionadas.

Lo que me preocupa es que si esta secuencia de comandos alguna vez se refacta y & dividirse, o la estupidez intencional se convierte en tu problema, o algún atacante escribe un script del lado del cliente aparentemente para ayudar a la gente, ... entonces estás en problemas.

Un posible problema es que solo se necesita un individuo inteligente (que podría ser lo suficientemente experto para usar esa técnica para usar una contraseña que falla el verificador y, sin embargo, es seguro!) para encontrar una manera de piratearla y distribuir el hack a algunas otras personas (que él / ella probablemente considere lo suficientemente responsables) que eventualmente se lo entregarán a las personas contra cuya falta de competencia de seguridad se suponía que la solución debía proteger.

Aplicar reglas en el servidor

Independientemente de las reglas que configure, deben aplicarse en el nivel del servidor en todos los casos. Esto se aplica a la configuración de la contraseña y, por ejemplo, a los campos obligatorios en los formularios (por ejemplo, si se requiere un número de teléfono al registrarse, debe verificarse en el servidor).

Ayuda a tu usuario en el cliente

Independientemente de las reglas que aplique en el servidor, debería ayudar a su usuario tanto como sea posible al brindar ayuda al cliente.

Puede ser solo una explicación, las estrellas junto a los campos obligatorios, mostrar errores antes de enviar formularios, ...

Pero aplique las reglas en el servidor

Pero en cualquier caso, no puede confiar en el cliente en absoluto. Algunas personas bloquearán JS. Algunas personas bloquearán el flash. En algún momento, puede abrir su API a terceros, lo que puede o no aplicar sus reglas por usted.

Por mi parte, a veces he vuelto a activar los botones bloqueados de JS porque descubrí que las reglas impuestas por el cliente eran ridículas (por ejemplo, su contraseña debe tener exactamente 8 caracteres, incluida una letra mayúscula, un número y un especial). solo en (! @ # $% & *?), con la esperanza de que el servidor no esté aplicando esas reglas (que a menudo no lo hizo).

Si sus especificaciones deben tener un conjunto de reglas precisas para la contraseña de sus usuarios, la validación del lado del cliente no cumple con las especificaciones.

Espero que la empresa de pruebas de lápiz aplique un principio general aquí: "hacer toda la validación del lado del servidor" sin considerar el caso específico con mucho detalle.

En su escenario, donde JavaScript no se puede desactivar, no veo ningún riesgo práctico para la seguridad. Puede haber un riesgo no técnico si necesita contraseñas complejas para un requisito reglamentario (por ejemplo, PCI-DSS).