¿Este método de autenticación evitaría que los MiTM obtengan la contraseña?

La respuesta es no.

  

El servidor responde con un identificador único para el inicio de sesión

Este paso en sí mismo contiene un defecto. Un MITM puede simplemente interceptar esta respuesta, cambiar el identificador único y observar cómo el cliente envía el identificador cifrado + el nombre de usuario. Si el atacante tiene tablas de arco iris pre-calculadas para cada identificador único que se inyecte, entonces obtener la contraseña es trivial.

Esto es apenas más seguro que transmitir la contraseña de texto simple.

Por supuesto, el algoritmo de cifrado debería resistir los ataques conocidos de texto simple, pero esto no es un problema (AES es).

Pero incluso si un MitM no pudiera calcular directamente la contraseña a partir del texto cifrado que grabó, él fácilmente podría ejecutar un ataque de diccionario sin conexión y simplemente probar muchos hashes de contraseña hasta que descifre el identificador con éxito. El método habitual de eliminar las contraseñas para que los ataques de diccionario sean ineficientes no funciona aquí, ya que tanto el servidor como el cliente (y, por lo tanto, el usuario) tendrían que conocer la sal.

Si controla la aplicación, ¿el cliente tiene por qué no incrustar una clave pública en el cliente y usarla para cifrar los detalles de inicio de sesión? Sería difícil reemplazar la clave, etc. pero sería simple y robusta, especialmente si tiene un canal de distribución seguro para la instalación del software original para evitar que se cambie la clave.

Si realmente tuvieras que encontrar una manera, creo que esto funcionaría:

1. El cliente envía el nombre de usuario al servidor
2. El servidor calcula HMAC (usersHashedPasswordFromDB, randomToken)
3. Envía el resultado al cliente junto con el formulario de inicio de sesión
4. El cliente calcula HMAC (slowHash (contraseña), randomToken)
5. Verificaciones de clientes (2) = (4)
6. El cliente sabe que randomToken proviene de alguien que conocía el hash de su contraseña: el servidor
7. El cliente calcula quickHash (slowHash (contraseña) + randomToken) (slowHash en caché desde antes)
8. El cliente envía el hash al servidor
9. El servidor calcula quickHash (usersHashedPasswordFromDB + randomToken) y lo compara con el hash proporcionado

Donde quickHash () es una implementación de hash segura rápida y slowHash () es una función adecuada con sal y función de trabajo que es la misma en el cliente y el servidor, posiblemente utilizando dominio y nombre de usuario como la sal, por ejemplo.

Aún sería vulnerable a un ataque de diccionario, ya que el único secreto es la contraseña del usuario, pero esto puede ser mitigado por el bloqueo o el retroceso del servidor en intentos fallidos (aunque esto representa un riesgo de denegación de servicio).

Feliz por las entradas y comentarios / correcciones.