Tengo conexión TLS entre mi servidor y el cliente. No tengo certificado, por lo que la conexión es susceptible al ataque Man-in-the-middle.
Me temo que el atacante podría interceptar el hash de la contraseña y usarlo para autenticarse en mi aplicación.
¿Cuál es la mejor manera de transmitir hash de contraseña? ¿Usar el servidor nonce o el cliente nonce? ¿Y qué algoritmo de hash debería usar?
Debería consultar Fijación de certificados .
Esto le permite efectivamente confiar en su certificado autofirmado, y ese certificado de servidor solo de su cliente mediante una búsqueda exhaustiva de la clave pública del certificado. Por lo tanto, no se sigue la cadena de autoridad (que es donde cae un certificado autofirmado) y, en su lugar, la clave es validada por la aplicación cliente para que se confíe directamente.
No debes ver el hash, ni nada más en la capa de la aplicación, ya que será inherentemente susceptible a un ataque MITM.
No puedes.
No hay una forma segura de transmitirlo si no puede autenticar el servidor y establecer un canal seguro. Si no puede autenticar el servidor, entonces no puede estar seguro de si está hablando con el servidor o el atacante. Por lo tanto, incluso si usa TLS para establecer un canal seguro, no lo protegerá en absoluto, ya que podría estar hablando con el atacante mientras piensa que está hablando con el servidor.
El certificado es esencial. Sin ella, o algún conocimiento de la clave pública del servidor, no puede estar seguro de que realmente se está comunicando con el servidor, ya que un atacante podría actuar como un hombre en el medio entre usted y el servidor.
TLS usa Diffie-Hellman para el intercambio de claves. Si observa la sección security de la página de wikipedia, encontrará el siguiente ataque, que es exactamente a lo que eres vulnerable.
En la descripción original, el intercambio Diffie-Hellman por sí mismo no proporciona autenticación de las partes comunicantes y es así vulnerable a un ataque de hombre en el medio. Mallory podrá establecer dos intercambios clave distintos, uno con Alice y el otro con Bob, efectivamente disfrazado de Alicia a Bob, y viceversa, permitiéndole para descifrar, luego volver a cifrar, los mensajes pasados entre ellos.
Conclusión
Necesitas tener un certificado válido para poder autenticar el servidor o serás vulnerable a los hombres en el ataque central. Una forma fácil de lograrlo es incluir el certificado del servidor en su aplicación, que también se conoce como fijación de certificado .
Agrupe su propio certificado de CA raíz con su aplicación y configúrelo para rechazar todos los certificados que no sean de confianza. Si solo usa su propio certificado CA, esto es posiblemente más seguro que confiar en las CA normales, ya que los atacantes han comprometido a las CA en el pasado y están sujetos a las políticas y autoridades gubernamentales.
Rodar su propio esquema de autenticación es imprudente, y es casi seguro que sea menos seguro que simplemente usar TLS con un certificado incluido.
Dado que otros ya han mencionado sobre la autenticación TLS y qué se puede hacer con respecto a ese problema, me centraré en:
¿Cuál es la mejor manera de transmitir hash de contraseña?
MITM es una de las amenazas en su escenario. Otra posible amenaza (también muy común) es una violación de datos. Usted debe considerar el caso en el que su base de datos podría estar comprometida y debe tomar las precauciones necesarias también en el lado del servidor. Hashear contraseñas en el lado del cliente no es una buena idea, a menos que no confíe al servidor con sus contraseñas y las vuelva a incluir en el servidor. Supongo que no es el caso con su escenario porque el servidor es el suyo.
Si los hashes de contraseña, enviados por los clientes, se almacenan como están en la base de datos, un atacante puede hacerse pasar por todos los usuarios enviando al servidor las contraseñas de hash de la base de datos tal como están. Las contraseñas de hash simplemente servirán como tokens de acceso secreto en este caso. Lea esto para obtener más detalles.
¿Y qué algoritmo de hash debo usar?
Algunas buenas funciones de hash (para almacenar contraseñas en el servidor) incluyen bcrypt, scrypt y PBKDF2. Echa un vistazo a increíble respuesta de Thomas Pornin para saber por qué son mejores. Básicamente, estas funciones, si se usan correctamente, harán que la tarea de un atacante sea mucho más difícil en caso de una violación de datos.
Utilice SRP ( S ecure R emote P assword) mecanismo de TLS.
El cliente y el servidor se autentican entre sí basándose en el conocimiento de una contraseña compartida que nunca se envía (esto significa que cualquier cosa que use como contraseña, en este caso, el hash) tendrá que ser almacenado en texto sin formato por el servidor). / p>
Lea otras preguntas en las etiquetas passwords authentication hash