El hashing de la contraseña del lado del cliente antes de enviarlo desde el formulario de inicio de sesión [duplicado]

3

Acabo de darme cuenta de que mi aplicación web está enviando contraseñas sin cifrar desde el formulario de inicio de sesión. Es así: he analizado, esa cadena enviada por el usuario desde el formulario de inicio de sesión está encriptada con MD5 (que es un error en sí misma, pero esa es una historia diferente) en el lado del servidor y se compara después de eso (las contraseñas en la base de datos están ocultas ).

He planteado el problema en mi rastreador de problemas interno, que debería reemplazarse con el uso de Javascript lib para hash contraseña directamente en el formulario de inicio de sesión, por lo que nunca se enviaría en texto sin formato. Inmediatamente recibí un comentario de uno de nuestros desarrolladores de que esto es incorrecto, ya que requiere que el usuario tenga activado Javascript. Y, ese problema debe resolverse mediante el uso de HTTPS, no mediante el uso de contraseñas de hashing en el lado del cliente.

Tengo mi opinión personal sobre todo esto " requiere Javascript para estar habilitado ", lo cual no es importante en este momento. Pero, me gustaría obtener una respuesta clara, cuál de nosotros está equivocado. ¿Realmente está obligando al usuario a habilitar Javascript un pecado más grande que el envío de su contraseña al servidor? ¿Y qué hay de la situación, cuando mi aplicación se ejecute en HTTP, no en el servidor HTTPS (por muchas razones)?

    
pregunta trejder 02.07.2014 - 13:26
fuente

3 respuestas

7

Desde el punto de vista del atacante, ya sea que envíe una contraseña de texto sin formato o un hash MD5 o no haga mucha diferencia, siempre que enviar el mismo valor de nuevo desbloquee la puerta. Recuerde, ingresar es el objetivo principal, no obtener el valor exacto de la contraseña. Entonces, si el atacante intercepta la contraseña con hash, enviarla nuevamente desde su casilla produce el mismo resultado: se acepta el inicio de sesión. Usar HTTPS sería la mejor solución, ya que protege todos los datos.

EDITAR: En lo que respecta a la situación en la que se accederá a su aplicación a través de HTTP simple, bueno, entonces están equivocados. A menos que haga rodar su propio protocolo ( NO SE RECOMIENDA ) para cifrar la contraseña del lado del cliente y descifrar, hacer hash y validarla del lado del servidor, la contraseña quedará expuesta.

    
respondido por el Dmitry Yanushkevich 02.07.2014 - 13:37
fuente
6

enlace

    
respondido por el aviv 02.07.2014 - 13:40
fuente
0

En mi opinión, enviar una contraseña de texto claro es un pecado y un riesgo más grandes porque el pirata informático necesitará menos experiencia (es decir, oler la contraseña de texto claro del servidor) en comparación con el uso de javascript (el pirata informático necesitará más experiencia). y también, ¿por qué no proteger sus cookies en su lugar? ¿Quieres no marcar tus cookies como httponly?

    
respondido por el H3lp3ingth3p33ps 02.07.2014 - 13:32
fuente

Lea otras preguntas en las etiquetas