¿El envío de una contraseña encriptada o como SHA1 es más seguro que el texto simple?

6

Me parece que si un atacante puede interceptar mi solicitud de inicio de sesión (enviada con HTTP POST), entonces puede reproducirla más tarde, sin importar si intento ofuscarla o no.

¿Qué me estoy perdiendo?

    
pregunta Mawg 26.06.2016 - 10:13
fuente

3 respuestas

9

Supongo que estás hablando de hash adicional. Así se vería así:

Client --sha1(password)--> Server --bcrypt(sha1(password)--> Database

Creo que está al tanto de esto, pero solo para hacerlo explícito: la transferencia debe realizarse a través de SSL para defenderse contra los espías, el hashing del lado del cliente no será de ninguna ayuda para ellos.

Hash u ofuscando una contraseña del lado del cliente puede ser una buena mitigación contra la reutilización de la contraseña:

Incluso si un atacante accede a la contraseña en texto sin formato, ya sea en transferencia o en el servidor, aún así tendría un hash, por lo que un atacante no puede probar las mismas credenciales en otros sitios web sin descifrar el hash.

  

Me parece que si un atacante puede interceptar mi solicitud de inicio de sesión, puede reproducirla más tarde, no importa si intento ofuscarla o no.

Sí. Hashing del lado del cliente no agrega ninguna seguridad a su aplicación, la única ventaja es que mitiga el mal comportamiento del usuario, lo que puede afectar a otras aplicaciones que el usuario también está utilizando.

Tenga en cuenta que ni siquiera protege a su aplicación de la reutilización de contraseñas, ya que un atacante que obtuvo las credenciales de los usuarios de otra aplicación solo la procesaría e intentaría eso.

Tampoco agrega ninguna complejidad al proceso de descifrar los hashes almacenados. Un atacante no intentaría una lista de hashes como entrada, sino una lista de palabras normal, que primero pasarían por sha1.

    
respondido por el tim 26.06.2016 - 10:38
fuente
2

Como escribió Tim, podría ayudar a mitigar los efectos de la reutilización de la contraseña para los usuarios en algunos casos, pero si lo que está pensando es en el lado del cliente, en lugar de , en el lado del servidor, este sería un defecto de diseño importante.

enlace

Este problema afecta a la autenticación NTLM, donde en realidad es aún peor que en el escenario de servicio / aplicación web común, ya que los hashes a menudo se almacenan en caché en sistemas distintos al servidor que maneja su autenticación.

    
respondido por el berdario 26.06.2016 - 13:14
fuente
-1

Su contraseña sha1 simplemente se convierte en la contraseña simple para un cuentagotas.

Lo que hago es lo siguiente:

En la base de datos, cada contraseña se cifra con bcrypt y un salt. La sal es "pública".

Cuando el usuario inicia sesión, sucede lo siguiente: - > cliente enviar nombre de usuario - > respuesta del servidor con "sal" - > cliente genera un nonce aleatorio - > cliente envía "bcrypt (nonce + bcrypt (salt + contraseña) + tiempo) + + tiempo + nonce" - > el servidor verifica que el nonce no se haya usado en los últimos 5 minutos, luego verifica la contraseña. Se realiza comparando la entrada enviada desde el cliente con "bcrypt (nonce + dbvalue + time)". - > para el usuario no existente, se envía una sal de miel.

Es bastante difícil de piratear, pero requiere del lado del cliente Javascript para los navegadores.

Incluso si uno está bajando los ojos, el hash bcrypt se revisa cada vez con un nuevo punto y tiempo.

Esta respuesta es realmente fácil de equivocar, así que hice un diagrama:

También,veaaquíporquéagregoestacapaadicionalinclusoconSSL: enlace

    
respondido por el programaths 26.06.2016 - 21:20
fuente

Lea otras preguntas en las etiquetas