¿El hashing del lado del cliente puede mejorar la seguridad después del hecho en respuesta a las filtraciones de contraseñas?

13

Varias preguntas en este sitio abordan el hash de la contraseña del lado del cliente, y ninguna de ellas admite ningún beneficio de seguridad más allá de la protección de otros otros sitios para los cuales el usuario podría usar la misma contraseña.

Sin embargo, parece haber una circunstancia que no se ha abordado, en la que creo que el hashing del lado del cliente puede mejorar la seguridad posterior a algunos escapes, especialmente Heartbleed. La mejor respuesta a estos errores es, de hecho, cambiar las contraseñas, sin embargo, los usuarios dudan en hacerlo y los sitios web casi nunca desean solicitarlo.

Imaginar hashing fue así.

  • El cliente tiene una contraseña de texto sin formato.
  • Esto se debe a H0 y luego a H1 .
  • Esto se envía al servidor, que contiene a H2 , que está almacenado en la base de datos.

Luego digamos que sucede Heartbleed, o algún pirata informático introduce el código en el hasher para enviarse un correo electrónico H1 a sí mismo, o cualquier otro error de seguridad que comprometa completamente el servidor (pero no el cliente) durante algún período de tiempo. El exploit se descubre y se arregla, pero todos los hash H1 se consideran comprometidos.

Digamos, como muestra la experiencia, restablecer la contraseña de todos no es una respuesta aceptable por motivos comerciales.

Con este método, se puede solucionar esto.

  • Parche al cliente para que envíe ahora (y el servidor requiera ahora) el hash H0 .
  • H0 se convierte en la nueva contraseña.
  • H0 es desconocido para los hackers, pero aún es verificable por el servidor.
  • Si es necesario, se puede producir un hash alternativo, H1 ', desde H0 para reemplazar H1 .

Obviamente, esto todavía revela lo suficiente como para permitir ataques locales de fuerza bruta por parte del atacante, por lo que no es una cura completa. Sin embargo, parece mucho más preferible que filtrar la contraseña de texto sin formato, especialmente si el usuario no está dispuesto a actualizarla o, en el mejor de los casos, la reemplazará por "${old_password}2" .

Sé poco sobre seguridad, así que es probable que haya pasado por alto algunas advertencias importantes. ¿Pensamientos?

    
pregunta Veedrac 26.07.2015 - 23:01
fuente

3 respuestas

1

No hay beneficios teóricos del hashing del lado del cliente y del servidor al hashing dos veces del lado del servidor; a menos que no se pueda confiar en la conexión entre el cliente y el servidor.

Sin embargo, en la práctica, he visto varias instancias en las que las contraseñas de texto sin formato terminaron en los registros (principalmente en los registros de errores). En este escenario particular tiene una clara ventaja.

Creo que el hashing de H0 a H1 es factible con un salt que es único por contraseña.

Una vez que H1 está en peligro, porque el servidor conoce este Salt en particular, el cliente podría autenticarse enviando H0, y luego el servidor puede verificar que H0 + Salt = > H1. Luego, el servidor podría cambiar la Sal a Sal 'y registrar la Sal H0 +' = > H1 'como la nueva contraseña.

Creo que esto es posible, pero no lo recomendaría: La complejidad es el enemigo de la seguridad.

    
respondido por el Nate 27.07.2015 - 00:02
fuente
1

El hash de la contraseña antes de la transmisión ocurre para algunos protocolos de autenticación, especialmente WAP / WPA2 PSK apretón de manos de cuatro vías . En este escenario, el protocolo WPA debe evitar un ataque de enmascaramiento, por lo que un AP no autorizado no puede obtener la contraseña de texto sin formato cuando se solicita a los clientes la autenticación.

En este protocolo, un atacante que haya obtenido H1 = hash(H0) puede usar este valor para autenticarse sin necesidad de conocer la contraseña de texto claro. Que es una infracción de CWE-294: omisión de autorización por reproducción de captura . Además, existe una preocupación con el cálculo de un hash de contraseña utilizando hash(hash'(H0)) , ya que no se usa una contraseña-salt ( CWE -759 ), y por lo tanto, un ataque de precomputación plantea el "camino más corto al compromiso".

Si se implementa correctamente, un sistema de autenticación basado en prueba de contraseña de conocimiento cero reduce significativamente el impacto que genera la divulgación de memoria ataques como Heartbleed, vulnerabilidades de divulgación de registro y algunos aspectos de MITM. Sin embargo, el descifrado de contraseñas basado en diccionarios no se ve afectado.

    
respondido por el rook 27.07.2015 - 00:41
fuente
0

Creo que la falla en tu plan es tu declaración

  

H0 es desconocido para los hackers, pero aún es verificable por el servidor.

Este no es el caso. Recuerda que los hashes son una forma. Todo lo que el servidor ha recibido de usted es H1, que se ha convertido en H2 (y que ahora está comprometido). El servidor no sabe cuál fue la entrada que generó H1 (es decir, H0). Además, se supone que el servidor solo ha mantenido H2 y no retiene H1. Si hubieran retenido H1, entonces sí, podrían tener H0 y comparar con H1, pero han mantenido H2.

Si lo piensas, si bien H1 es lo que originalmente enviaste al servidor, desde la perspectiva del servidor, es solo una contraseña, una contraseña potencialmente larga, pero solo una contraseña. El servidor entonces necesita hash esa contraseña para almacenarla (creando H2). También esperamos que el servidor no tenga registro de H1. Cuando se autentica, envía H1, que el servidor utiliza para obtener H2. Para que su esquema funcione, el servidor también tendría que mantener H1, lo que sería como mantener una contraseña de texto simple. Una vez que un pirata informático se apoderó de la base de datos de hashes H1, puede acceder al servidor como el usuario asociado con ese hash sin tener que hacer nada más.

La otra parte de su sugerencia, que probablemente necesite más reflexión, es

  

Parchea el cliente para enviar ahora (y el servidor ahora requiere) el hash H0.

Ese es un problema potencial o, al menos, es probable que sea tanto trabajo como simplemente cambiar su contraseña. Si tuviera que permitir este tipo de cambio automáticamente y, por lo tanto, reducir / evitar la necesidad de que el usuario tome medidas, está abriendo otro posible problema de seguridad: cómo / quién iniciaría ese parche y cómo evitaría el parche no autorizado. Si desea que el usuario realice la aplicación de parches, probablemente se requiera más esfuerzo para hacerlo bien que solo para cambiar su contraseña.

EDITAR: Como se señaló en el comentario, se puede verificar el hash H0 mediante el hash dos veces H0 - > H1 - > H2 y comparando con el H2 que tiene el servidor. Así que tal vez esa parte de la ecuación podría funcionar.

Sin embargo, la aplicación de parches o la coordinación del cambio de usar H1 a usar H0 sigue siendo un problema IMO. Los mecanismos de actualización / parche "normales" no funcionarán, ya que dichos mecanismos se basan en una única "fuente de verdad" de confianza. Por ejemplo, si está en Windows confía en el servicio de actualización de Windows y si está en OSX, confíe en el servicio de actualización de OSX. Pero con respecto a los sitios web, estamos tratando con infraestructura descentralizada.

Considere un entorno en el que todos o algunos subconjuntos de todos los servidores web hayan adoptado este esquema. Si un servidor web está comprometido, de alguna manera es necesario que el servidor informe al cliente que ahora necesita enviar H0 en lugar de H1. En este punto, las cosas comienzan a ser muy complejas y la complejidad es el enemigo natural de la seguridad.

No puede realizar el cambio globalmente, es decir, ahora requiere que todos los sitios que usan este esquema utilicen H0 en lugar de H1 porque esto causaría un problema de coordinación. De alguna manera, tendría que decirle a todos los servidores que usan el esquema que cambien a H0 - > H1 - > Método h2. Ahora tiene que actualizar los servidores y los clientes y coordinar ese cambio o algunos sitios dejarán de funcionar.

Por lo tanto, deberá hacerlo por sitio. Esto significa que necesitaría tener algún mecanismo integrado en su esquema que le permita al servidor indicar al hash que desea para la autenticación: H0 o H1. Ahora tienes otro problema. ¿Cómo se protege contra un servidor falso que solicita H0?

Dado que uno de los mayores problemas con cualquier esquema de contraseña es que las personas tienden a usar la misma contraseña en varios sitios. Sabemos que esto es una mala práctica, pero la gente lo hace de todos modos. Si fuera a visitar un servidor defectuoso, podría pedir H0. Ahora ese servidor tiene H0 y puede hacerlo para obtener H1 y usar ese hash para acceder a otros servidores que podría usar que aún dependen del H1 original como contraseña. Esto incluso podría ser parte de otro vector de ataque en hosts comprometidos: una vez que haya comprometido a un host, podría comenzar a solicitar hashes H0.

el verdadero problema aquí es que estamos agregando complejidad adicional, lo que agregará 'agujeros' imprevistos que solo agregan la mínima seguridad adicional posible y no solucionan el enfoque fundamental (y probablemente no solucionable) del uso de contraseñas para garantizar el acceso. Estas contraseñas como un control de acceso en sí mismas simplemente se rompen. Lo que realmente se necesita es una forma conveniente de agregar factores adicionales al proceso de autenticación y alejarse de los enfoques que se basan en una simple palabra secreta

    
respondido por el Tim X 06.12.2015 - 00:59
fuente

Lea otras preguntas en las etiquetas