¿Cuáles son las desventajas de combinar la seguridad de autenticación del lado del cliente y del servidor?

Navega tus respuestas
1

Imagina la situación:

  • La aplicación puede o no ejecutarse a través de SSL / TLS
  • La aplicación no debe saber la contraseña del cliente porque el cliente podría reutilizar las contraseñas

¿Entonces el hash combinado de la contraseña del lado del cliente y del servidor no funcionaría mejor?

¿Cómo funcionaría la creación de contraseñas?

  1. El usuario ingresa la contraseña en un campo.
  2. El javascript del lado local contiene la contraseña con el nombre de usuario que proporciona sal
  3. Estos datos con hash se transmiten a través de la red al servidor.
  4. El servidor agrega sal generado aleatoriamente al hash y recalienta a ambos en un nuevo hash. Este nuevo hash y sal aleatoria del lado del servidor se almacenan

Cómo funcionaría el inicio de sesión:

  1. El usuario ingresa la contraseña en un campo.
  2. El valor del campo de "inicio de sesión" se toma como salt y hash de cómputo del lado local.
  3. Este hash se transmite a través de la red al servidor
  4. El servidor toma la sal almacenada para ese usuario, combina el hash con la sal y la hace hash.
  5. El servidor compara el hash nuevo con el hash almacenado, si coincide, el usuario inició sesión correctamente. Si no coincide, se deniega el acceso al usuario.

¿Cuál sería una desventaja de este enfoque en comparación con el enfoque estándar con la transmisión de contraseñas de texto simple a través de Internet y luego la mezcla y el almacenamiento en el servidor?

    
pregunta Enerccio 16.06.2015 - 15:38
fuente

3 respuestas

1

No hay una gran desventaja en el uso de javascript para eliminar la contraseña, pero hay pocas ventajas. Esto proporciona protección contra una captura pasiva, pero no ofrece más seguridad sobre SSL.

El atacante tiene un MiTM activo o tiene el control del servidor

En el caso de que el atacante pueda Man in The Middle una conexión entre el cliente y el servidor, el atacante puede sustituir la biblioteca de JavaScript por la suya, eliminando así cualquier protección.

El atacante obtiene una captura pasiva

En el caso de que el atacante obtenga una captura pasiva del tráfico entre el cliente y el servidor. Si el sitio web no usa SSL, entonces el tráfico del sitio web es vulnerable a un MiTM, por lo tanto, mientras que una captura pasiva no se puede descifrar, el atacante solo se posicionará en el medio. Si el sitio web utiliza SSL, el texto plano ya está protegido. Tenga en cuenta que podría presentar un argumento de protección contra SSL en el que el sitio web no implementa un secreto perfecto y el certificado SSL es robado.

Si está interesado en la implementación de crypto en el navegador, debe consultar RFC 2617 que explica cómo implementar hashes de contraseña. en la autenticación HTTP. Idealmente, el navegador expondría una interfaz a una biblioteca criptográfica, pero hay algunos aspectos a considerar. Por ejemplo, en el escenario que describiste anteriormente, la falta de un nonce haría que el usuario sea vulnerable a un ataque de repetición.

    
respondido por el amccormack 16.06.2015 - 16:41
fuente
1

En su esquema, está sustituyendo la contraseña por su hash. El hash se convierte en la contraseña. Un atacante que puede rastrear el hash puede autenticarse en su servidor sin saber la contraseña. El atacante solo tiene que crear una solicitud HTTP correcta y enviarla a su servidor, o editar el javascript de su página web de inicio de sesión en su propio navegador para reutilizar el hash que acaba de detectar.

Al final, el hash de la contraseña en el navegador solo aumenta la complejidad del protocolo de autenticación sin aumentar la seguridad de ninguna manera.

    
respondido por el Anonymous Coward 16.06.2015 - 18:19
fuente
0
  

¿Cuál sería una desventaja de este enfoque en comparación con el enfoque estándar con la transmisión de contraseñas de texto sin formato a través de Internet y luego la mezcla y el almacenamiento en el servidor?

  1. Los usuarios que usan varias computadoras, algunas con JavaScript activado y otras con JavaScript desactivado, no podrán autenticarse desde algunas de sus computadoras y es posible que no sepan por qué. Admito que este es probablemente un grupo muy pequeño de personas.

  2. Si el hash transmitido es interceptado, puede ser utilizado por un atacante como la contraseña con solo algunas modificaciones al JavaScript (como lo indica Anonymous Coward).

  3. Si se implementa ingenuamente, esto haría que el nombre de usuario sea sensible a mayúsculas y minúsculas, pero esto podría mitigarse haciendo que JavaScript convierta el nombre de usuario a minúsculas antes de usarlo como sal

respondido por el Owen 16.06.2015 - 18:47
fuente

Lea otras preguntas en las etiquetas

Antitampering de la tableta [cerrado] ¿WebCrypto también exige que los algoritmos de cifrado se implementen en Javascript?