Contraseñas de hash antes de enviar al servidor

Question

Al enviar contraseñas a través de la transferencia de socket codificada UTF-8, ¿se considera seguro si tengo la contraseña usando MD5 o SHA-1 antes de enviar los datos? Tenga en cuenta que planeo comparar la contraseña hash en una base de datos SQL. Me preocupa que alguien pueda olfatear la contraseña hash en UTF-8 luego descifrar la codificación UTF-8 y podría obtener mi contraseña hash que podría ser utilizada para hacer coincidir la contraseña en mi base de datos.

Answer 1

Si el cliente simplemente envía la contraseña hash, la contraseña hash es la "contraseña": una secuencia de bytes que el cliente solo necesita mostrar para ser autenticado. Si el atacante puede oler eso, entonces tu protocolo está condenado al fracaso.

Si el protocolo de autenticación consiste simplemente en presentar un dato secreto (llámalo contraseña si lo deseas), el intercambio debe realizarse en un medio de transporte que garantice la confidencialidad (para que los datos secretos no puedan ser olfateados) y autenticación de servidor (para que un atacante no pueda imitar un servidor y convencer a un cliente de que le envíe los datos secretos). Esto es lo que obtienes de un túnel SSL/TLS clásico (una URL https://, en un contexto web).

Si no puede establecer un túnel SSL/TLS con autenticación de servidor (es decir, el servidor tiene un certificado que el cliente puede verificar), entonces puede recurrir a un protocolo de autenticación con un desafío: el servidor envía una secuencia de bytes aleatorios (el desafío) y el cliente responde con un valor hash calculado sobre la concatenación de la contraseña y el desafío. ¡No intente esto en casa! Es muy difícil hacerlo bien, especialmente cuando el atacante puede interceptar comunicaciones (ataques activos).

Una respuesta más genérica es password-authenticated key exchange protocols. PAKE combina un protocolo de acuerdo de claves criptográficas (como Diffie-Hellman) y autenticación mutua de contraseñas entre el cliente y el servidor, de una manera que derrota tanto a atacantes pasivos como activos, incluso con contraseñas relativamente débiles (el atacante no puede obtener datos suficientes para "probar" contraseñas sin interactuar con el cliente o el servidor para cada conjetura). Desafortunadamente, pocos algoritmos PAKE se han estandarizado más allá de la descripción matemática, y el área es un campo de minas patentado.

Answer 2

Podrían forzar la fuerza bruta de sus contraseñas si conocen el algoritmo hash. La solución simple (y no perfectamente segura) es usar un desafío/respuesta en su lugar, el servidor emite una cadena aleatoria ("nonce") para ser procesada junto con el hash de contraseña. Esto hace que tu aplicación sea invulnerable al tipo de ataques de repetición que estás describiendo.

Para obtener más información, consulte de digest access authentication

Answer 3

¿Cómo se comprueba la contraseña en el lado de la base de datos HTTP?

Si almacena el hash sin salr de la contraseña y simplemente lo compara con la entrada, la contraseña del hash se puede olfatear y reutilizar.

Es exactamente como si estuviera almacenando la contraseña en sí en la base de datos en texto plano.

Si tiene miedo de oler, use un protocolo de desafío-respuesta para autenticarse, pero en este caso el secreto se almacenará en la base de datos (y será conocido por cualquiera que tenga acceso a la base de datos).

Como alternativa, puede enviar una contraseña en texto sin formato a través de un canal protegido (SSL), pero tendrá que instalar un certificado que probablemente le cueste algo de dinero (si usa una autorización de un proveedor lista, es decir, uno de los navegadores de sus clientes no se quejará)

Answer 4

Bueno, si alguien puede oler el hash, puede falsificar la solicitud de autorización y enviar el hash que ya conoce.

Hacer un sistema seguro no es fácil, necesitaría hacer una autorización mediante criptografía asimétrica con claves debidamente firmadas para que sea seguro.

Al menos agregue ~ 100byte de sal aleatoria, y use SHA1 - de esta manera sería mucho más difícil aplicar fuerza bruta.

Answer 5

Hm, si está hablando de 'correcto' hash, eso significa que 'encriptará' su contraseña para que no se pueda descifrar, porque el hash es una función de una manera, y para descifrarlo - hasta tómese un tiempo, y algún tipo de gran CPU power.

Si le preocupan los rastreadores de contraseñas, puede llevarlo al siguiente nivel: use el cifrado de clave PRIVADO/PÚBLICO. El servidor debe enviar un desafío al cliente (clave pública para el cifrado), el cliente lo cifra y solo el servidor sabe cómo descifrarlo. Por la misma cantidad de bits, ofrece más protección, es decir. se necesita más músculo para romper la fuerza bruta.

Verificar this salir.