¿Cuáles son los pros y los contras de un sal aleatorio entre el cliente y el servidor?

Navega tus respuestas
3

Al investigar sobre las mejores prácticas en las contraseñas de hash usando una sal, encontré un presentation en slideshare. El enfoque descrito es el siguiente

  
  1. El cliente solicita la página de inicio de sesión
    2.   
  2. El código del lado del servidor genera un SALT aleatorio y envía el SALT de vuelta al cliente junto con el formulario de inicio de sesión
    3.   
  3. El JavaScript del lado del cliente genera un hash de la contraseña ingresada por el usuario agregado a la sal (hashpwd + sal) llamada A y la envía a   servidor junto con el nombre de usuario
    4.   
  4. El código del lado del servidor recupera la contraseña hash para este usuario de la base de datos y la usa para generar un nuevo hash (hashpwd + salt), llamado B.
    5.   
  5. El código del lado del servidor compara A y B y, si coinciden, el usuario está autenticado.
    6.   
  6. La sal se destruye en el lado del servidor.
    7.   
  7. La siguiente solicitud de inicio de sesión genera una nueva SALT que solo sobrevive para esa solicitud.
    8.   

En este enfoque, las contraseñas se almacenan en la base de datos hash pero sin un salt. Entonces, si las contraseñas son robadas (como LinkedIn), ¿estoy en lo cierto al decir que este enfoque es inútil? Sin un hash, la contraseña se puede descifrar con relativa facilidad. ¿Qué protección ofrece este enfoque? Creo que previene los ataques de repetición al generar una nueva SALT y también hace que los ataques de fuerza bruta desde el front-end también sean imposibles. Me interesaría escuchar información sobre este enfoque y una buena lista de ventajas y desventajas del enfoque. No soy un experto en seguridad por cualquier tramo de la imaginación.

    
pregunta Peter Kelly 19.06.2012 - 16:42
fuente

3 respuestas

4

De hecho, este enfoque no ayuda contra el robo de la base de datos de contraseñas. Es más fácil ver por qué: se refiere solo al intercambio de datos y no afecta el formato de la base de datos. Dado que la base de datos almacena los hashes directos de las contraseñas, es vulnerable a un ataque de la tabla del arco iris, lo que hace que todas las contraseñas, salvo la más alta de la entropía, se puedan romper.

Este valor aleatorio de una sola vez es un nonce , y dichos valores se usan comúnmente en los protocolos de comunicación para evitar la reproducción. los ataques. Sin un nonce, un atacante podría escuchar una conversación legítima y luego reproducir la fase de inicio de sesión con el servidor. Es posible que encuentre dichas implementaciones porque es útil bajo las siguientes hipótesis:

  • la comunicación utiliza HTTP;
  • el atacante puede escuchar pasivamente todas las comunicaciones TCP / IP, pero no puede hablar directamente con ningún cliente, solo con el servidor.

Hay aplicaciones web antiguas diseñadas bajo estas hipótesis. Agregar un nonce a la fase de inicio de sesión fue una carga importante para los atacantes en los días en que en su mayoría eran estudiantes universitarios aburridos en los campus universitarios. En el mundo actual de las herramientas de red y dispositivos de computación avanzados ubicuos, asumir que las conexiones TCP no pueden ser secuestradas no es realista. Dicho protocolo es vulnerable a un ataque de hombre en el medio donde el atacante proporciona una respuesta de DNS falsa al cliente o secuestra la conexión TCP. El uso de HTTPS (con la autenticación adecuada del servidor, es decir, la validación adecuada del certificado) hace que la adición de un nonce al protocolo de inicio de sesión sea redundante (el propio HTTPS contiene un nonce para que las conexiones no puedan reproducirse).

    
respondido por el Gilles 19.06.2012 - 17:45
fuente
2

Usted tiene razón al decir que este tipo de sal no retrasa el descifrado de contraseñas si se obtiene una base de datos de contraseñas. Las tablas de arco iris pueden usarse para descifrar contraseñas fácilmente.

Desde mi (muy limitada) experiencia, no he visto ninguna implementación de tal característica.

Realmente no veo cómo evitaría que una fuerza bruta fuera atacada desde la interfaz de la aplicación, ya que se genera, agrega y compara un nuevo salt cada vez, mientras que el hash de la contraseña sigue siendo el mismo.

Lo único que se me ocurre es que esto impide que un atacante pase una sesión de inicio de sesión como otra (sales diferentes cada vez), aunque esas cosas podrían rastrearse fácilmente a través de los registros.

Notas : en realidad no he hecho clic en las diapositivas y estoy basando mi respuesta del esquema que dio.

Me interesaría escuchar opiniones contrarias, ya que realmente no puedo ver cómo esto es útil en absoluto.

    
respondido por el Ayrx 19.06.2012 - 17:18
fuente
2

En tales usos es un nonce, no un SALT, y lo que estás describiendo es una forma de protocolo de respuesta de desafío. Consulte CRAM-MD5 para obtener un protocolo estandarizado similar al que está sugiriendo (se trata de un paso diferente).

    
respondido por el ewanm89 19.06.2012 - 17:48
fuente

Lea otras preguntas en las etiquetas

¿Tengo un virus en mi sitio alojado? ¿Cómo fue atrapado Lulzsec? [cerrado]