¿Cuáles son las implicaciones de seguridad de almacenar múltiples hashes para contraseñas similares? [duplicar]

Si hay algún impacto en los aspectos técnicos de la seguridad, ya sea positivo o negativo, parece ser muy marginal. Califico "técnico" porque los elementos humanos / psicológicos a menudo desempeñan un papel importante.

El impacto real es solo el usuario real, cuya vida se hace marginalmente difícil y quizás en el lado positivo, más consciente de la seguridad.

Desde el lado del servidor, veo esto como un trabajo adicional (tanto durante el desarrollo como en las operaciones) que no brinda el beneficio suficiente para justificarlo. Para defenderse de cualquier ataque de diccionario de atacante con talento moderado, el número de hashes que se deben almacenar de esta manera es demasiado grande para que tenga sentido a escala.

¿Por qué? El factor de trabajo del atacante no ha cambiado mucho, a pesar de haber eliminado "algunas" de las combinaciones.

OTOH, la concientización del usuario puede manejarse mejor en el lado del cliente al calificar la seguridad de la contraseña mientras el usuario la escribe. Esto puede incluir pruebas de entropía (longitud, variedad, etc.) así como Pruebas de unicidad (variación de contraseña anterior). No es necesario almacenarlo en el lado del servidor, IMHO.

Recuerda, no necesitas almacenar variantes en absoluto.

En caso de que desee que la nueva contraseña coincida con la contraseña anterior one , puede pedirle al usuario que ingrese ambas al cambiarla y medir la distancia de edición mínima entre el par.

Por supuesto, muchos recomendarían no hacer nada con contraseñas, excepto el hash. En ese caso, simplemente podría generar todas las variantes de la contraseña nueva y comparar los hashes con los de todas las contraseñas antiguas (sin necesidad de almacenar todas las variantes antiguas).

En ningún momento almacenará variantes de contraseñas o sus hash, mientras sigue realizando verificaciones básicas de similitud.

  

Tengo curiosidad por las implicaciones de esto en la seguridad. Estos hashes   darían más oportunidades para un forzador bruto, ¿no?

Creo que no, el sistema comprobará la contraseña que eligieron. La fuerza bruta solo atacará eso. Las versiones alternativas solo se utilizarán cuando un usuario cambie su contraseña.

Incluso si el atacante pudiera realizar un ataque fuera de línea contra todas las variantes en su tiempo libre, probablemente solo atacarían al que no ganan nada al forzar brutalmente contra cada hash con cada intento de texto sin formato.

  

Son esencialmente colisiones. Aunque por otro lado, te   esperar que si alguien es de fuerza bruta, probablemente probaría el   variaciones alrededor de un tiempo similar, por lo que parece que no lo haría   necesariamente ahorrar mucho tiempo de fuerza bruta.

No son colisiones en absoluto, se trata de cuando dos textos sin formato tienen el mismo hash . Cada variante tendrá un hash totalmente diferente al otro. Nadie podría decir que el texto sin formato era similar de todas formas.

  

Tampoco estoy seguro de cuánto importan las colisiones si la contraseña   es lo suficientemente seguro Por ejemplo, si tenemos 10 variaciones hash, que   teóricamente significa que se necesitarían 10 veces menos intentos de brutal   forzar la contraseña, ¿verdad?

Lo siento pero está mal, como dijo, el protocolo de autenticación solo comprobará la contraseña que eligió el usuario, y en segundo lugar, 10x no sería el caso, incluso si comprobara todas las variantes, ya que no es 10 veces menos intentos.

  

Entonces, sí, ¿el hash de estas variaciones debilita significativamente la seguridad?   ¿Es lo suficientemente pequeño como para que no importe (particularmente en comparación con   los beneficios de evitar la reutilización de contraseñas similares)?

Así que para resumir. Si el protocolo de autenticación solo comprueba la contraseña elegida por el usuario, entonces no. Incluso si comprobara todas las variantes, solo reduciría la entropía en una cantidad significativamente pequeña. Los hashes tampoco compartirían una estructura común entre sí, por lo que incluso con el acceso a los hashes, no será más sabio.

También puedo agregar, lo anterior se basa únicamente en la pregunta que formuló el OP. Pero sabemos que, obviamente, las contraseñas de hash no son buenas, por lo tanto, incluso si las contraseñas fueron "hash" usando una función de Derivación de clave basada en contraseña adecuada, la respuesta seguiría siendo válida.

  

Tengo curiosidad por las implicaciones de esto en la seguridad. Estos hashes darían más oportunidades para un forzador de brutos, ¿no es así? Son esencialmente colisiones.

No veo cómo son "colisiones" en ningún sentido del término.

  

Aunque, por otro lado, uno esperaría que si alguien es forzado brutalmente, probablemente probaría las variantes en un tiempo similar, por lo que parece que no necesariamente ahorraría mucho tiempo de forzado bruto.

Y esta observación tuya, me parece, casi responde la pregunta. Podemos apelar a la ley de Kerckhoff para asumir razonablemente que el cracker sabrá acerca de su técnica de hash múltiple, qué mutaciones aplica a las contraseñas de los usuarios, qué entradas son tales mutaciones para cuáles entradas reales, etc. Así que la solución más simple para el cracker es simplemente ignorar todos los hashes para variantes mutadas y concentrarse en las contraseñas reales.

En el peor de los casos, cuando maximizamos el conocimiento del atacante, los hashes adicionales no tienen ningún efecto en la seguridad.

NIST ha publicado recientemente un nuevo BORRADOR de las pautas de contraseña. El blog de Sopho hace un bien trabajo de explicar los cambios en términos sencillos.

En resumen, no es necesario que almacenes varios HASH, porque:

• Tu HASH debe ser salado usando un algoritmo fuerte y cada instancia de ese HASH debe ser completamente diferente, lo que hace que compararlos sea discutible.
• Las recomendaciones de NIST hacen que el desarrollador compare las contraseñas con un diccionario conocido.

Longitud de la contraseña

Lo que sabemos es que la longitud de la contraseña es más importante que las reglas de complejidad arbitrarias. La razón de esto es que la cantidad de entropía de la contraseña no está definida por la contraseña de un usuario, sino por el conjunto de símbolos permitido que un desarrollador le da al usuario para crear una contraseña.

Un conjunto de símbolos más grande aumenta los bits de entropía.

Contraseñas del diccionario

El gran movimiento es poner la seguridad en los desarrolladores. Esto incluye verificar la contraseña de un usuario contra conjuntos de contraseñas comunes de un diccionario. Esto hace dos cosas, reduce drásticamente la superficie de ataque. Los atacantes estarían limitados a los diccionarios más grandes (potencia de cálculo), y la fuerza bruta que obliga a las contraseñas de más de 8 caracteres no es razonable para la mayoría de los atacantes.

Para que pueda desarrollar conjuntos de reglas de contraseña de forma pragmática para buscar cualquier contraseña de diccionario. p.ej. Si su contraseña era IAmTheWalrus, su dicción podría detectar a Walrus y decirle al usuario que la contraseña contiene una palabra del diccionario. Podrían ingresar a IAmTheWa! Rus, pero una contraseña de 12 caracteres como esa es una magnitud mejor que los ataques de diccionario comunes.