Enviar contraseña a través de una conexión no segura

Question

Enviar contraseña a través de una conexión no segura

#1 de LSerni (3 votos)

-1

Estoy desarrollando un programa que necesita usuarios para iniciar sesión. El tráfico no es sensible pero tiene que viajar lo más rápido posible, por lo tanto no estoy asegurando la conexión a través de TLS o algo así. Lo único sensible es la contraseña y probablemente el nombre de usuario (que será la dirección de correo electrónico). Antes de transferirla o de cifrarla con una clave pública RSA, pensé en eliminar la contraseña en el lado del cliente, el problema es que, si un atacante puede obtener este hash o contraseña encriptada, puede iniciar sesión fácilmente usando este hash directamente si modifica el hash. Cliente, así que necesito algún tipo de salazón. El problema es que: el servidor almacenará la contraseña con sal + hash, por lo que cuando el cliente haga la contraseña con un salt diferente cada vez, producirá un hash diferente. Con el cifrado, el servidor solo puede descifrar la contraseña + sal y eliminar la sal. Ahora me pregunto si hay una manera sin cifrado, solo con hash, de que pueda transportar mi contraseña de forma segura al servidor y prohíba que un atacante simplemente reutilice la contraseña hash ?

Mis pensamientos:

El servidor almacena la contraseña con salt1 , hash. El servidor envía salt1 y aleatoriamente (cada conexión una nueva) salt2 al cliente. El cliente salta y hashs la contraseña con salt1 , sales y hashs el hash desde el paso 1 nuevamente con salt2 , envía este hash al servidor. Entonces, para verificar la contraseña que el servidor tiene para saltear y hash, se almacena el hash con salt2 y ver si hay igualdad. ¿Esto es seguro?

passwords hash

pregunta tkausl 17.08.2016 - 00:20

fuente

1 respuesta

Lea otras preguntas en las etiquetas passwords hash

¿Inyección de SQL con el operador LIKE? ¿Se puede usar la criptografía para comparar y verificar las respuestas de los servidores web que no son de confianza? [cerrado]

score 3 · Answer 1

Puede usar la misma técnica que la Autenticación de resumen de HTTP (en realidad, podría usar exactamente esa técnica, reutilizando cualquiera de las varias bibliotecas existentes).

El servidor envía un desafío, el cliente responde (por ejemplo) combinando el desafío y el secreto. El servidor se cuida de no reutilizar un desafío.

Dependiendo de la mecánica de la conexión, es posible que deba volver a autenticar la conexión en cada solicitud. Para reducir los gastos generales, es posible que desee utilizar algún tipo de fuente incremental, es decir,

client                     server
login request ------>      user's password is "squeamishossifrage"
          <--- 12345       challenge
hash      (MD5("12345:0:squeamishossifrage")
          <--- OK ---
          ---> MD5("12345:1:squeamishossifrage")

Usando HTTP con Digest-Auth esto se hace automáticamente. Usando HTTP simple, simplemente puede agregar un encabezado o un parámetro a cada solicitud.

El servidor almacena la contraseña salada con salt1, hash. El servidor envía salt1 y un aleatorio (cada una nueva conexión) salt2 al cliente. El cliente saca y hash la contraseña con salt1, sal y hash el hash del paso 1 otra vez con salt2, envía este hash al servidor. Entonces, para verificar la contraseña que el servidor tiene para saltear y hash, se almacena el hash con salt2 y ver si hay igualdad.

Esto está bien, pero es equivalente a almacenar la contraseña en el borrado. Para todos los efectos, conocer la contraseña salt1-ed es suficiente para realizar un inicio de sesión exitoso; esto significa que si uno tuviera acceso a la base de datos de contraseñas, podría usarla tal como está sin necesidad de descifrado.

Usted tiene tiene una ventaja sobre el almacenamiento de las contraseñas, y esto es así, de esta manera no debe preocuparse por la reutilización de la contraseña (es decir, el usuario usa una contraseña que es la misma que la suya). contraseña para otro servicio. Cualquier persona que obtenga acceso a su base de datos también obtiene acceso a este otro servicio).