¿Las contraseñas de hash en mi caso de uso mejorarán la seguridad y por qué?

Navega tus respuestas
1

Estoy desarrollando una aplicación cuya arquitectura está organizada de la siguiente manera:

Session host <---> Central relay server <---> Session client

Toda la comunicación entre el session host de inicio y el session client de conexión posterior se retransmite a través del servidor central.

El session host debe protegerse de manera tal que no se pueda acceder sin una clave de sesión pública que lo identifique y una contraseña privada que haya estipulado de antemano.

De hecho, ninguna comunicación debería ser posible con el session host a menos que el session client pueda demostrar al servidor central que está autorizado, es decir, que la autenticación debe tener lugar en el mismo servidor central.

En el flujo de trabajo que tengo en mente:

  1. El session host se conecta al servidor central a través de TLS, enviando un hash de su contraseña elegida.

  2. El servidor central responde con una clave de sesión generada que identifica el host de la sesión.

  3. El session client se conecta al servidor central especificando la clave de sesión y el hash de la contraseña intentada.

  4. El servidor central verifica los hashes para una coincidencia, si hay una coincidencia, los mensajes session client s pueden pasar al session host , si no hay una coincidencia, la autenticación ha fallado.

Por lo tanto, mi pregunta es la siguiente.

¿El hash de la contraseña de esta manera proporciona alguna seguridad adicional en lugar de simplemente enviar las contraseñas estipuladas y las contraseñas intentadas? ¿Cómo debo manejar la salazón?

Me inclino a pensar que vale la pena, ya que significa que la contraseña completa nunca se envía a través del cable, incluso si se trata de TLS. Ni siquiera se almacena en la memoria RAM en el servidor central. Protege la contraseña del usuario, pero no ofrece seguridad adicional para la sesión ya que el hash se convierte en la contraseña.

Gracias

    
pregunta user3560041 26.01.2015 - 17:22
fuente

3 respuestas

1

Como usted mismo ha dicho, el hash se convierte en la contraseña en este caso. Por lo tanto, no es más o menos seguro. Y nuevamente identificó correctamente que el único beneficio real es que el usuario no puede exponer su contraseña en caso de reutilización. Personalmente, me sentiría tentado a generar contraseñas para el host y luego les daré los detalles para enviar al cliente.

Pero, en realidad, solo importa si sus usuarios están colocando sus contraseñas reales en otros lugares en el cuadro de contraseña. Por lo tanto, la mejor solución si no te gusta la de arriba podría ser redactarla de manera un poco diferente para que en cambio peguen una frase o lo que sea allí en lugar de una contraseña.

    
respondido por el AlexH 26.01.2015 - 17:38
fuente
3

En su escenario, los hash agregan poca seguridad porque el cliente envía el hash al servidor central, sin embargo, el cliente debe enviar el intento de contraseña, el servidor central luego compara el hash de la contraseña con el hash enviado.

El hash es muy importante en este escenario, ya que puede tener un usuario malicioso. El usuario malintencionado tiene una cuenta y una contraseña reales, luego se conecta al servidor host a través del servidor central de manera normal. Luego se conecta al servidor host y, si puede explotar una vulnerabilidad en este servidor, puede volcar las contraseñas de texto simple de todos los demás usuarios. La distribución de sal debe manejarse de la manera habitual, es decir, el host envía al servidor central un hash y un salt, y el cliente envía una contraseña de texto simple a través de TLS, y el servidor verifica que la contraseña y el salt coinciden.

    
respondido por el jhoyla 26.01.2015 - 17:58
fuente
0

Sé que esta es una pregunta antigua, pero pensé que lo sopesaría.

Normalmente, el cliente envía 'X' (contraseña de texto sin formato), que el servidor convierte a 'Y' (hash) y almacena. El beneficio es que lo que el cliente conoce y transmite no es lo mismo que se almacena en la base de datos del servidor.

Lo que creo que estás proponiendo es que el cliente tome 'Y' y lo envíe al servidor, donde se almacena como 'Y'. Así que básicamente estás almacenando las contraseñas como texto simple, aunque ese texto simple sea un hash. Esa no es la mejor práctica, aunque no creo que sea necesariamente mala en este caso, ya que la contraseña original del usuario no se expondrá en el caso de una pérdida de la base de datos. Dicho esto, no veo ningún aspecto bueno de este enfoque, ya que la conexión TSL ya cifra la contraseña de texto sin formato mientras viaja a través del cable. Creo que el servidor siempre debería hacer algo de salado y hash, incluso si el cliente también hace algo de hash.

    
respondido por el Lakey 05.05.2015 - 04:55
fuente

Lea otras preguntas en las etiquetas

¿Puedo crear un certificado SSL en Windows firmado con el certificado de la máquina? Aparte del token del sincronizador, ¿existe alguna forma de protección contra CSRF utilizando encabezados http?