hashing del lado del cliente / salazón a través de HTTPS

Question

Me pregunto cuáles son los problemas graves son con la siguiente configuración:

Nombre de usuario esquema de usuario / contraseña Javascript / Ajax pide al valor de la sal desde el servidor (que hemos establecido en las preguntas anteriores sal no es un valor secreto) Javascript preformas una SHA1 (o no) de la contraseña y la sal. Javascript / Ajax regresar el hash al servidor El servidor se aplica otra sal / almohadilla en la parte superior de la la enviada a través de AJAX.

Las transacciones son a través de HTTPS.

Me preocupan los problemas que puedan existir, pero no pueden convencer a mí mismo que esto es tan malo de un montaje. Supongamos que todos los usuarios tener Javascript activado como jQuery es muy usada en el sitio. Se trata básicamente de intentar agregar una capa adicional de seguridad al texto plano de una contraseña.

Answer 1

Todo ese esfuerzo de pasar sales y hashes entre el cliente y el servidor ya está integrado en el protocolo subyacente HTTPS / SSL. Yo estaría muy sorprendido si una capa de seguridad en javascript va a ayudar mucho. Recomiendo hacer que sea sencillo y el uso de texto plano a través de SSL en el lado del cliente. La preocupación sobre el cifrado en el lado del servidor.

Answer 2

Como siempre:. Tener mucho cuidado con el diseño de protocolos criptográficos mismo

Pero eso se dice, puedo ver la ventaja en el esquema. Es protección contra la contraseña que se revela a través de un hombre-en-el-medio-ataque y asegurarse de que el servidor nunca ve la contraseña real, evitando así que algunos dentro de ataques. Por otro lado, no protege contra el hombre-en-el-navegador, pesca, etc.

Es posible que desee leer a través de RFC 2617 acerca de la autenticación de acceso HTTP Digest. Ese esquema es similar a lo que se propone.

Answer 3

Esto no añade ningún tipo de seguridad adicional. El código JavaScript está presente en el cliente, por lo que se conoce el algoritmo de hash. Usted no gana nada de hacer un hash del lado del cliente en este caso.

Además, no hay ninguna razón por la cual el cliente debe saber acerca de la sal de hash. En realidad, debe es un valor secreto, especialmente si usted está utilizando una sal común.

Answer 4

Usted no está ganando nada. No hay ningún punto de una sal si Joe Public lo puede ver haciendo clic en Ver> Fuente, y la vieja máxima de que nunca confiar entrada del cliente el doble para hash de la clave.

Si realmente desea aumentar la seguridad, utilizar un hash basado SHA-2 (SHA-224/256/384/512), como SHA-1 tiene vulnerabilidades potenciales. NIST ya no recomienda SHA-1 para aplicaciones que son vulnerables a los ataques de colisión (como los hashes de contraseñas).

Answer 5

Voy a 100% en desacuerdo con la respuesta aceptada y decir que bajo ninguna circunstancia debe una contraseña original siempre siempre siempre dejar el cliente. Siempre debe ser salado y hash. Siempre, sin excepción.

Dos razones ... . El cliente no debe ser confía que todos los componentes de servidor y redes internas son TSL. Es bastante común para el punto final TSL sea un equilibrio de carga de proxy inverso, que se comunica con los servidores de aplicaciones usando texto claro porque DevOps no puede ser molestado para generar certs servidor para todos sus servidores internos.

. Muchos usuarios se inclinan patológicamente utilizar una contraseña común para todos sus servicios. El hecho de que un servidor tiene contraseñas en texto plano, aunque sólo en la memoria, hace que sea un objetivo atractivo para los ataques externos.