¿Cómo es útil el hashing de contraseñas en el ataque MITM?

El hash de contraseña se utiliza para proteger a los usuarios en el caso de que una base de datos se vea comprometida. La transmisión de la contraseña al servidor es un escenario de seguridad completamente diferente.

Sus dos afirmaciones sobre el rastreo de tráfico al comienzo de su pregunta son correctas. Transmitir la contraseña en texto simple permite a un atacante oler la contraseña. El cálculo del hash en el lado del cliente esencialmente hace que el hash sea la contraseña, por lo que un atacante puede simplemente olfatear el hash y usarlo en su lugar.

Para responder a tus preguntas al final:

1. HTTPS usa SSL (o TLS) para proporcionar seguridad de punto a punto. Básicamente, esto significa que un atacante no puede rastrear los datos, ya que están cifrados. Tampoco puede inyectar datos, ya que también se proporciona autenticidad. Cuando se utiliza SSL, el servidor tiene un certificado que contiene su clave pública. El certificado está firmado por una CA en la que su navegador confía, para que pueda verificar que es correcto. Su navegador genera una clave de sesión y la cifra utilizando la clave pública del servidor. Solo el servidor puede descifrarlo, porque solo el servidor conoce la clave privada. Una vez que tanto el servidor como el cliente conocen la clave de sesión, pueden comunicarse de forma segura.

2. Un ISP o proxy puede usar un ataque de intermediario para presentarle un certificado falso. Si acepta ese certificado, pueden descifrar la conversación e inyectar sus propios datos. Sin embargo, su navegador le avisará que el certificado no es válido. Algunos gobiernos obtienen certificados reales para este fin, por lo que no se dará cuenta a menos que inspeccione el certificado.

3. Si el atacante conoce su contraseña WPA2, puede conectarse a la red. Esto les permite oler el tráfico.

En su situación, envíe la contraseña a través de HTTPS, luego córtela en el lado del servidor con un algoritmo de derivación de clave fuerte como PBKDF2 o bcrypt.

Como dijo el polinomio, el hashing no se trata de proteger una contraseña transmitida. Es para que, si alguien ingresa a su base de datos, no tenga todas las contraseñas al instante.

Si está preocupado por un ataque MITM, una cosa que podría intentar es usar un nonce. Di que quieres enviar la contraseña. Primero envía una solicitud al servidor para generar una cadena aleatoria. Toma la cadena devuelta, y en lugar de enviar hash (pass) envía hash (hash (pass) + nonce). Luego, el servidor compara eso con el hash + nonce almacenado para autenticar. Incluso si el atacante olfatea el hash, no puede reutilizarlo porque cada nonce es un uso de una sola vez.

El hash de contraseña no es para la seguridad de las contraseñas mientras se transmiten por cable, sino para almacenamiento en el servidor. Hundimos contraseñas porque a veces sucede (más a menudo de lo que nos gustaría) que las personas malas vean los archivos y / o la base de datos del servidor. Para lo que sucede en el cable, necesitamos dos cosas:

• Necesitamos integridad porque la autenticación siempre es relativa a algunos datos intercambiados posteriormente. No queremos un atacante, en posición de ejecutar un ataque MitM , solo esperar la autenticación se realizará y luego secuestrará la conexión en vivo, "autenticada".

• Necesitamos confidencialidad porque no queremos que los atacantes observen las contraseñas en tránsito, o incluso el hash de las contraseñas, porque un hash de contraseña es suficiente para "probar las contraseñas en casa". Más generalmente, generalmente preferimos que los datos confidenciales que estamos a punto de intercambiar se mantengan confidenciales (no siempre es así, pero a menudo sucede).

SSL proporciona ambos. Cuando se usa SSL (llamado HTTPS en un contexto web), la conexión está protegida contra alteraciones, encriptada, y el cliente está razonablemente Seguro de hablar con el servidor correcto. Bajo estas condiciones, la contraseña puede enviarse del cliente al servidor sin ningún tipo de hash aplicado, y eso es exactamente lo que sucede en la mayoría de los sitios web donde escribe su nombre de usuario y contraseña. El servidor todavía debe almacenar, en algún lugar de su base de datos, algunos datos que permitan la verificación de la contraseña enviada por el usuario; que el elemento de datos debe ser la contraseña con hash (con el surtido habitual de protecciones: hashing lento, sales ...).

Creo que la pieza que falta para ti es el uso de sales. Tienes razón en que el envío de un hash no es bueno, ya que puede ser detectado, se puede usar una sal para proteger el hash de la contraseña. Una sal es un fragmento de datos aleatorizados con hash que se agrega al hash de la contraseña, luego todo se vuelve a hash. spw = hash (hash (pwd) + sal). Puedo enviar el spw más el salt al otro lado, que luego puede usar la versión almacenada localmente de la contraseña para autenticarse.

El MiTM puede interceptar spw y la sal, pero para obtener pwd tendría que hacerlo con fuerza bruta, lo que sería computacionalmente costoso y requeriría mucho tiempo. Tenga en cuenta que esto es vulnerable a los ataques de reproducción, por lo que no estoy defendiendo lo anterior como un método de autenticación, el punto es que al agregar un salt, el MiTM no puede obtener el hash de la contraseña. El Protocolo de autenticación Challenge Handshake es un ejemplo de la forma en que se usan las sales en la autenticación, pero si realmente quiere evitar que los ataques MiTM use claves públicas-privadas.