Si uso SSL, ¿necesito cifrar la contraseña antes de enviarla al servidor? [duplicar]

Question

Si uso SSL, ¿necesito cifrar la contraseña antes de enviarla al servidor? [duplicar]

#1 de lights0123 (1 votos)

0

Estoy configurando un sitio web para ayudar a las personas con ciertos intereses de nicho a encontrarse entre sí. Se está realizando únicamente como un proyecto voluntario, no hay dinero involucrado (de ningún lado), ni hay mucha información personal almacenada. Los únicos datos interesantes que almacenamos son el código postal, la dirección de correo electrónico y la contraseña (hash) de cada usuario. Todo lo que se obtendría al tener acceso a estos es la capacidad de cambiar el código postal del usuario, lo que me parece poco beneficioso para cualquiera.

Sin embargo, se ha señalado que muchas personas usan la misma contraseña en todas partes, por lo que si alguien pudiera acceder a los datos, podrían probar la misma combinación de correo electrónico / contraseña en otros sitios. Si bien esto parece una tarea pequeña y probablemente inútil, queremos asegurarles a nuestros usuarios que los estamos protegiendo.

Si ejecutamos el sitio a través de SSL, entonces, cuando se registran o inician sesión, ¿hay algún gran beneficio en el hashing de su contraseña en Javascript antes de enviarlo al servidor? Por otro lado, estamos exponiendo algo que no deberíamos hacer al hacer hash en Javascript, donde está abierto para que cualquiera lo vea, a diferencia de en el servidor, donde solo es visible para las personas con acceso al servidor (en cuyo caso tenemos otros problemas de seguridad)?

P.S. Tenga en cuenta que no soy un experto en seguridad de ninguna manera, así que no asuma ningún conocimiento previo. Si me he perdido algún punto obvio, aclárelo o solicite más detalles, en lugar de hacer una votación negativa como una mala pregunta. Busqué, pero no he encontrado nada que responda a esta pregunta (¡aunque aprendí muchas otras cosas a lo largo del camino!)

P.P.S. Tenga en cuenta que esta pregunta está específicamente relacionada con el proceso de registro e inicio de sesión. Obviamente hay preguntas sobre la seguridad de la base de datos, etc., pero se están tratando por separado.

web-application passwords authentication hash

pregunta Avrohom Yisroel 28.05.2017 - 16:43

fuente

1 respuesta

Lea otras preguntas en las etiquetas web-application passwords authentication hash

¿Puedo forzar la comunicación entre la aplicación y el servidor para que no use DHE / ECDHE? ¿Se pueden ver las URL durante las transacciones HTTPS / 2 a uno o más sitios web desde una única IP distinguible?

score 1 · Accepted Answer

Generalmente, no hay razón para cifrar las contraseñas del lado del cliente. Consideremos una situación sin SSL primero, pero con cifrado de contraseña:

Bob está iniciando sesión en su cuenta. Él va a la página de inicio de sesión, ingresa su nombre de usuario y contraseña, e ingresa. Mientras Eve está monitoreando el intercambio, ella no ve la contraseña, ya que está encriptada.

Esto solo sucedería, sin embargo, si Eve solo está monitoreando la conexión (lo cual es casi nunca). Esto es lo que realmente sucedería si Eve pudiera modificar la conexión:

Bob está iniciando sesión en su cuenta. Él va a la página de inicio de sesión. Sin embargo, Eve intercepta esta solicitud y elimina el código de cifrado. Bob ingresa su nombre de usuario y contraseña e inicia sesión. Mientras Eve está monitoreando el intercambio, sí ve la contraseña, ya que no está encriptada. Para que Bob no sospeche nada, reenvía la solicitud con la contraseña cifrada al servidor y devuelve el token de sesión a Bob.

En esta situación, podemos ver que el cifrado es inútil cuando el código de cifrado puede verse comprometido. Sin embargo, sería útil cuando el código de la aplicación puede ser confiable (por ejemplo, entregado por un CD y firmado por el desarrollador) y los datos se intercambian a través de una conexión insegura (es decir, sin SSL). Este no es el caso con un sitio web a través de HTTP.

¿Qué pasa si esto se hizo sobre SSL? Bueno, todavía no tendría sentido el cifrado del lado del cliente. El atacante no podría ver el intercambio, y si estuviera comprometido, entonces podría usarse el ataque que se muestra arriba. Además, esto plantea un punto de rodar tu propio cripto: sí, no estás haciendo los algoritmos por ti mismo, pero estás utilizando el cifrado en algún lugar donde se realiza en otro lugar. Además, las personas que tienen JS deshabilitado o tienen navegadores sin la API criptográfica, todo funcionaría. El punto de cómo JS puede ser inseguro no es tan serio, ya que, a menos que se envíen encabezados HTTP específicos, JS podría capturar la contraseña de todos modos.