¿Por qué algunas personas realmente odian la seguridad a través del lado del cliente?

Lo que has descrito no es mejorar la seguridad del sistema. No es una cuestión de opinión o emoción, la seguridad simplemente no funciona de esa manera. En su ejemplo, hash(salt+password) es ahora su contraseña. Si no fuera por https, entonces un atacante podría simplemente reproducir ese valor. Además, realmente no te dirigiste a owasp a9 alias "estilo fuego".

Tiene que ver con el alcance general de lo que intenta proteger. Si está desarrollando una aplicación del lado del servidor, está intentando proteger el servidor tanto del usuario como de su sistema cliente. Hacer que el sistema del usuario (es decir, el cliente) haga su trabajo de seguridad por usted realmente no ayuda al servidor a mantenerse protegido. Por lo general, se supone que cuando el cliente está haciendo algo, incluso si funciona a instancias del servidor (en términos de JavaScript entregado por el servidor), el cliente no es confiable, porque un pirata informático puede tomar el control del lado del cliente. Aplicación y enviar la entrada por separado de JavaScript.

Un servidor hace un hash de contraseña para inhibir los problemas resultantes de la divulgación del almacén de contraseñas. Si un atacante retiene los hashes de contraseña, debería ser imposible utilizarlos enviando las contraseñas desde una máquina cliente pirateada, porque el servidor está haciendo su propio hash. Si el servidor delega este trabajo para el cliente, entonces el servidor también está delegando una función de seguridad.

Todo esto depende de cómo defina su límite de protección. Si tiene razones para creer que no hay absolutamente ninguna amenaza por parte de la máquina cliente y que no se puede piratear el sistema del cliente, este problema desaparece ... pero no conozco ningún sistema web que pueda hacer esta afirmación. .

La razón principal no es el odio ... es la inseguridad. Un principio general es no confiar en nada de lo que no tienes control. En el caso de que un usuario se autentique en una aplicación, a menos que haya proporcionado la computadora portátil al usuario, haya configurado sus controles y los del entorno en el que se encuentra, no puede confiar en ella.

La forma tradicional de verlo es que si un atacante tiene acceso físico a una computadora, puede hacer lo que quiera.

Con un navegador simple que solo configura un enlace cifrado, hay muy poco que pueda ser comprometido, con un cliente más grueso cualquier funcionalidad del lado del cliente podría estar comprometida.

Si está calculando el hash en el lado del cliente, agrega el riesgo de que un atacante solo necesite un hash de la contraseña de un usuario para iniciar sesión en lugar de la contraseña real. Probablemente podría evitar eso enviando un nonce para hash la contraseña con (básicamente, un sal por sesión), pero también tendría que hacerlo en el lado del servidor, así que ¿por qué molestarse en hacerlo en el cliente ?

No estoy seguro de si las personas "odian" los mecanismos que describe en el lado del cliente.

Creo que esto tiene más que ver con las prácticas heredadas y el soporte desigual en el cliente.

En primer lugar, necesita JavaScript para implementar esto, si desea hacerlo a través de la autenticación basada en formularios. HTTP Digest proporciona algo similar de forma nativa, y es compatible con la mayoría de los navegadores (incluidos los que no tienen JavaScript), pero no "se ve bien" y no se puede integrar muy bien con la marca general del sitio web. Para ser justos, tener una marca identificable en la que ingresará su contraseña también puede ser bueno desde el punto de vista de la seguridad. Además, una de las principales deficiencias de las implementaciones de HTTP Digest en los navegadores es que los cuadros emergentes no se ven muy diferentes de los que usan HTTP Basic, que no ofrece ninguna protección.

En segundo lugar, que yo sepa, el soporte para las funciones criptográficas de JavaScript varía de un navegador a otro. Si bien a veces puede ser tolerable tener un soporte inadecuado para ciertas funciones en los navegadores, el poder iniciar sesión es bastante fundamental y eso es algo que nunca querrá que se rompa.

Finalmente, todavía debes confiar en el código enviado por el servidor, por lo que no hay ningún beneficio aquí si, de todos modos, inicias sesión a través de HTTPS. Cuando envía su contraseña a través de HTTPS, la entrega al servidor y confía en que el servidor la maneje correctamente. Si no confía en el servidor lo suficiente como para darle su contraseña, no tiene sentido confiar en él con el JavaScript que le envía para realizar la autenticación.

Para su ejemplo específico, hay al menos una razón comercial y una razón de seguridad que no se puede hacer de esa manera.

Razón comercial

• El usuario requiere Javascript. Esto no siempre está necesariamente habilitado.

Razón de seguridad

• Las contraseñas se almacenan normalmente con un sal. Necesitarías una sal constante, lo que la haría menos útil; compartir la sal específica del usuario, que agrega complicaciones y nuevamente la hace menos útil (aunque no al grado de tener una sal constante); o tal vez un nombre de usuario basado en sal.

No todos los sistemas evitan usar un sistema como el que usted describe, Lastpass calcula los hashes en el lado del cliente (descritos en un podcast de Security Now ( transcripción ).

La seguridad en el extremo del cliente tiene un gran problema: usted asume que el cliente se va a comportar bien. ¿Y si no lo hacen? Así que les permite calcular un hash ... ahora tiene gente que usa tablas de hash calculadas previamente en su servidor a tasas súper rápidas, sacando uno de los principales beneficios del hashing: su lentitud. Si no lo hace, pero el servidor hace el hash para el cliente, entonces puede pedirle al cliente que pida millones de cadenas para hacer el hash, ralentizando el servidor ... Entonces, básicamente, es "elija su veneno". Debe elegir la respuesta según el conocimiento específico del dominio: ¿confía en sus usuarios? ¿Se trata de internet? Si es así, es probable que no quieras confiar en los usuarios.

Aprender sobre el análisis de protocolos es probablemente la mejor manera de entender por qué no quiere que los clientes hagan mucho relacionado con la seguridad. Los ataques de repetición, los ataques precomputados, todos ocurren porque le da a los clientes demasiada libertad, demasiada elección. Lea sobre el protocolo Needham-Schroeder-Lowe , cómo surgió, cómo descubrieron un ataque y cuál es la solución , es una gran demostración de cómo desea crear un protocolo que esté a salvo de clientes maliciosos.

Para responder a su pregunta, es suficiente entender el punto de las contraseñas de hash.

La razón por la que las contraseñas están en hash es para almacenar un derivado en lugar de la contraseña real. Esto evita que mallory inicie sesión en el servidor como una persona, incluso si hubiera comprometido la base de datos del servidor (un problema bastante común). Siempre escuchas que se revelan números de tarjetas de crédito y no contraseñas, porque las contraseñas con hash no son vulnerables de esta manera.

Esto también evita que Mallory descubra una contraseña que Alicia podría estar usando en otros sitios web / software.

Se puede observar, aunque no es necesario responder a su pregunta de que se utiliza un salt en los servidores al hash. Esto se hace para prevenir ataques de tabla arco iris, porque es posible iterar contraseñas aleatorias y hacerlas con algoritmos de hash comúnmente usados para almacenarlos en una tabla. Mallory ahora podría recuperar las contraseñas nuevamente haciendo una búsqueda en la tabla. Esta es una técnica común para recuperar las contraseñas del sistema operativo. (al menos las ventanas no usan / no usan sal). La esencia de un salt es que es único por instalación / sitio web y secreto (por lo general se almacenará en archivos php / config en lugar de en la base de datos con el resto de las contraseñas).

En la seguridad del lado del cliente. Lo que propone no es realmente la seguridad del lado del cliente, ya que solo se propone omitir un paso del procedimiento de almacenamiento de contraseñas. Tenga en cuenta que cada usuario es libre de usar un hash como contraseña.

El punto a entender es que siempre debe hacer seguridad en el extremo receptor de alguna conexión (especialmente pero no solo en un servicio de acceso público). Como cualquier persona puede conectar un servidor web, no puede confiar en nada de lo que entra. Cualquier seguridad que pueda haber ocurrido en un cliente debe realizarse de nuevo, ya que algún atacante podría fácilmente ignorar esa seguridad.

Como ejemplo de contador, tenga en cuenta que el cliente también tiene seguridad. Cuando el navegador es el extremo receptor , restringirá el acceso al sistema de archivos del host, por ejemplo, a los scripts en los sitios web.

Lamento llegar tarde a la fiesta ...

Las respuestas son correctas, ya que al usar el hash recibido tal como es para comparar con su base de datos, ha hecho el hash de la nueva "contraseña". Sin embargo, si agrega un desafío aleatorio (también conocido como "nonce"), el hash transmitido ya no podrá usarse como la nueva contraseña.

Estoy totalmente en desacuerdo con las respuestas que generalizan que la seguridad del lado del cliente es algo malo. Estamos utilizando el hashing del lado del cliente (usando un salt y un nonce) en un sitio web de alto perfil durante años. Principalmente por dos razones:

1. Evite que las contraseñas de texto sin formato terminen accidentalmente en los registros del servidor
2. Evite que los "ojos errantes" de los administradores del sistema aprendan las contraseñas

Al utilizar el hashing del lado del cliente, nunca estaremos expuestos a la contraseña de texto simple de los usuarios y, por lo tanto, reduciremos nuestra responsabilidad.

Actualmente estamos intentando diseñar el estiramiento de la clave en el sistema, lo que demuestra ser un poco más difícil. Consulte Desafío desafiante: el hashing de la contraseña del lado del cliente y la verificación de la contraseña del lado del servidor