Pregunta:
Hash de la contraseña del lado del cliente antes de enviarla desde el formulario de inicio de sesión
trejder
2014-07-02 16:26:10 UTC
view on stackexchange narkive permalink

Me acabo de dar cuenta de que mi aplicación web envía 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 tiene un hash con MD5 (lo cual es incorrecto en sí mismo, 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 son hash ).

He planteado el problema en mi rastreador de problemas interno, que debe reemplazarse con el uso de Javascript lib para aplicar un hash a la contraseña directamente en el formulario de inicio de sesión, para que nunca se envíe en texto plano. Inmediatamente recibí un comentario de uno de nuestros desarrolladores, que esto es incorrecto, porque requiere que el usuario tenga habilitado Javascript. Y ese problema debe resolverse utilizando HTTPS, no aplicando hash a las contraseñas del lado del cliente.

Tengo mi opinión personal sobre todo esto " requiere que Javascript esté habilitado " mierda, que no es importante en este momento. Pero me gustaría obtener una respuesta clara, cuál de nosotros está equivocado. ¿Es realmente un pecado mayor forzar al usuario a habilitar Javascript que enviar su contraseña sin formato al servidor? ¿Y qué pasa con la situación, cuando mi aplicación se ejecutará en HTTP, no en el servidor HTTPS (por muchas razones)?

Tres respuestas:
Dmitry Janushkevich
2014-07-02 16:37:08 UTC
view on stackexchange narkive permalink

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 hay mucha diferencia, siempre que enviar el mismo valor nuevamente 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 hash, enviarla nuevamente desde su caja produce el mismo resultado: inicio de sesión aceptado. Usar HTTPS sería la mejor solución, ya que protege todos los datos.

EDITAR: En cuanto a la situación en la que se accederá a tu aplicación a través de HTTP simple, bueno, entonces estás jodido. A menos que utilice su propio protocolo ( NO RECOMENDADO ) para cifrar la contraseña del lado del cliente y descifrarla, aplicar un hash y validarla del lado del servidor, la contraseña quedará expuesta.

En realidad, está equivocado: es trivialmente fácil implementar un sistema de desafío-respuesta para la contraseña hash que haría bastante más difícil reutilizar el mismo hash una y otra vez. (y con HMAC con clave, puede hacerlo aún mejor). El problema principal es que de todos modos no tiene sentido: o está usando HTTPS, en cuyo caso no está agregando ninguna seguridad al sistema en general o no lo está, en cuyo caso proteger la contraseña no tiene sentido, ya que todo lo demás, incluido claves de sesión: están en texto claro, por lo que es trivial piratear la sesión del usuario.
Buen punto con las claves de sesión. Y un buen punto a favor del uso de HTTPS. En cuanto al sistema de desafío-respuesta, estoy de acuerdo en que puede que no sea difícil implementarlo, y puedo ver el lado del cliente. Tengo un problema para entender el lado del servidor en este esquema. ¿Puedes explicar un poco más?
Simplemente agregue un desafío en el javascript que envía al cliente y asegúrese de escribirlo en su estado local. El servidor genera el estado de la sesión (marcado como "desafiado"), guarda el desafío y envía el javascript modificado. El cliente realiza HMAC y envía el resultado junto con el nombre de usuario, el servidor busca el nombre de usuario, realiza el mismo cálculo y verifica el resultado. Para no almacenar la contraseña del lado del servidor, simplemente almacene la primera mitad del HMAC. Por supuesto, esa sigue siendo una estrategia de almacenamiento de contraseñas bastante débil.
Es posible que haya leído mal la parte "almacenar la primera mitad del HMAC", pero ¿no requiere esto que el HMAC sea constante? Si es así, ¿cuál es el beneficio? De lo contrario, este esquema parece requerir un secreto compartido (podría ser una contraseña o su hash), que debe almacenarse para reproducir el resultado del lado del servidor de cómputo HMAC. Esto deja una posibilidad de daño inmediato en caso de que se filtre la base de datos (la razón principal para mantener las contraseñas hash, ¿verdad?)
Incluso si el mismo contenido hash siempre abriera la puerta, aún sería una mejora con respecto al envío de una contraseña de texto sin formato si el hash no pudiera ser efectivamente modificado por ingeniería inversa. Si se usa la misma contraseña tanto en un sitio http: como en uno https: uno, un buen algoritmo hash podría evitar que los ataques de escucha pasiva en el sitio http: expongan la contraseña al https: uno.
¿Significa que el desarrollador móvil debe POSTAR en la URL: https://www.domain.com cuando publica datos?
aviv
2014-07-02 16:40:08 UTC
view on stackexchange narkive permalink

https debe estar habilitado de todos modos y no debe usar http en su formulario de inicio de sesión Lo que dice su desarrollador al limitar la aplicación para que se sirva solo como https (debe configurarse en el servidor web) incluso si se envía la contraseña en texto claro en el formulario, todo el tráfico está encriptado y, por lo tanto, la contraseña es segura. Eso es correcto. Incluso si aplica un hash a la contraseña en su navegador y luego la envía a través de http, puede ser rastreada y robada. Para un atacante, el hash robado en este caso es tan bueno como la contraseña real. Incluso si no puede buscarlo en una tabla de arcoíris, puede enviar el hash en la solicitud de inicio de sesión.

H3lp3ingth3p33ps
2014-07-02 16:32:24 UTC
view on stackexchange narkive permalink

En mi opinión, enviar una contraseña sin cifrar es un pecado y un riesgo mayor porque el pirata informático necesitará menos experiencia (es decir, olfatear la contraseña sin cifrar 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? ¿Le gustaría no marcar sus cookies como httponly?

¿Cómo protegería exactamente las cookies del rastreo de tráfico? El indicador HttpOnly solo prohíbe el acceso a la cookie desde el código JS dentro del navegador; sin embargo, la cookie se transmite por cable; de ​​lo contrario, no tiene sentido configurar la cookie en absoluto.
esa fue una sugerencia.
No parece resolver el problema en cuestión. :-)
Cualquier protocolo de contraseña que no realice la autenticación del lado del navegador del JavaScript que se ejecutará en el cliente será susceptible a un ataque man-in-the-middle. Sin embargo, estoy de acuerdo con usted en que enviar una contraseña de texto plano a través de http: es un pecado mayor, porque esa contraseña no solo otorgará acceso a los sitios http:, sino que también puede otorgar acceso a los https :.


Esta pregunta y respuesta fue traducida automáticamente del idioma inglés.El contenido original está disponible en stackexchange, a quien agradecemos la licencia cc by-sa 3.0 bajo la que se distribuye.
Loading...