¿Es seguro almacenar un historial de hash de contraseña para evitar que el usuario mantenga la misma contraseña repetidamente en algunos casos?

Seguridad del almacenamiento del historial de hash

  

¿Es seguro mantener el historial de hashes?

Relativamente. Puedo imaginar algunos escenarios donde esto dañaría la seguridad del usuario, por ejemplo:

• Un usuario usa una contraseña relativamente débil, se da cuenta de esto y la actualiza a una mejor contraseña, basada en la contraseña anterior (ejemplo simple: superawesome - > !sup3eraw3s0m3! ), esto podría hacer que un atacante pueda para descifrar más fácilmente la contraseña ahora más segura (primero descifran la contraseña fácil, la tienen en su lista de palabras ahora y luego le aplican reglas básicas como e - > 3, etc.).
• Anteriormente, utilizaron una contraseña en su sitio web que también utilizan en muchos otros sitios web, dejaron de confiar en su sitio web y cambiaron la contraseña en su sitio web. Un atacante podría obtener su base de datos, descifrar su contraseña anterior (que pensaron que se eliminaría de su base de datos) y luego probar las credenciales de inicio de sesión en un sitio web diferente.
• Después de un tiempo, tienes un montón de historial de un usuario que cambia las contraseñas con frecuencia. Las grietas de un atacante suponen que el 30% de los hash de historial, y ahora tiene una idea bastante clara de cómo ese usuario específico crea contraseñas. Si el usuario no crea contraseñas realmente aleatorias, será mucho más fácil romper la contraseña actual.

Por lo tanto, no recomendaría mantener un historial de hash de contraseña.

Alternativa

  

¿Cómo puedo detenerlo para que mantenga la misma contraseña del historial anterior?

No llevar una historia. Cuando un usuario cambia su contraseña, todavía tiene el hash de contraseña original en la base de datos. Puede compararlo con eso para evitar duplicados exactos.

Pero usando bcrypt, esto sucede:

  

Según mi observación, si un usuario cambia su contraseña y mantiene la misma que la anterior, los valores de hash se vuelven diferentes

Sucede porque bcrypt administra automáticamente las sales por ti. Así que cuando hash una nueva contraseña, se trata con un salt diferente, y por lo tanto el hash es diferente. Puede recuperar la sal antigua , y luego pasarla a password_hash como argumento para obtener el mismo hash.

Mejor alternativa

También puede requerir que el usuario envíe su contraseña anterior al cambiar las contraseñas (lo que también aumenta la seguridad [*]), y luego puede incluso verificar si la nueva contraseña es similar a la antigua. (por ejemplo, utilizando una distancia de Hamming o similar).

Sin embargo, mis dos alternativas no evitan los cambios cíclicos (por ejemplo, super-secure-password - > another-awesome-credential - > super-secure-password ), pero no estoy seguro de si realmente estaría preocupado por eso.

_{[*] alguien que roba una sesión no puede cambiar la contraseña, y CSRF no puede cambiar la contraseña (incluso si hay una vulnerabilidad XSS).}

En realidad, los comentarios sobre cómo Google maneja las contraseñas antiguas (aún reconociéndolas para recuperar una cuenta bloqueada), me hicieron pensar en los pros y contras de esto, y si se podría usar para evitar que las personas reutilicen Contraseñas antiguas de forma relativamente segura. No es que realmente piense que querría eso (personalmente, creo que el 99% de las "mejores prácticas forzadas" para el uso de contraseñas simplemente hace que las personas escriban su contraseña; esto es cierto a menos que la persona involucrada realmente reconozca la importancia de la contraseña). por ejemplo, permite el funcionamiento de una planta de energía nuclear), en cuyo caso no es necesario aplicar las mejores prácticas de una manera tecnológica).

Primero veamos cómo Google puede haber implementado su sistema de una manera relativamente segura. De los comentarios anteriores, entiendo que cuando uno pierde el acceso a su correo electrónico y olvida su contraseña actual, se inicia algún tipo de flujo de recuperación-trabajo, donde se proporciona "evidencia" de su identidad. Probablemente en algún momento un humano tomará una decisión sobre si restaurar el acceso a esa cuenta. En ese momento, necesitan tanta evidencia como puedan encontrar que eres tú. El conocimiento de una contraseña anterior puede proporcionar una pista.

Ahora, los problemas de almacenar hashes de contraseñas antiguas son como @tim menciona en su elaborada respuesta: incluso a través de la sospecha de que Google asegura sus bases de datos mucho mejor que la mayoría de las demás, siempre puede ocurrir una violación de datos. Sin embargo, si en lugar de almacenar un hash de contraseña completo de 128 bits / 256 bits (con sal), solo almacenan los primeros 16 bits (para las contraseñas antiguas), será imposible para un atacante extraer una contraseña de este ^* . Al mismo tiempo, si alguien proporciona 2 contraseñas que coinciden con 2 de los 4 hashes de 16 bits almacenados, este es un gran indicio de que la persona no es un pirata informático completamente aleatorio ^** .

Diga que su requisito es no permitir ninguna contraseña que se haya usado antes en el sistema para ese usuario (por ejemplo, su jefe leyó en alguna parte que es una buena idea y no permitirá que nadie cambie de opinión). Una vez más, estoy totalmente de acuerdo con la evaluación de @ tim de que almacenar hashes para contraseñas antiguas es una muy mala idea. Entonces, ¿qué sucede si utilizamos la solución de Google sugerida y almacenamos solo un hash pequeño para obtener una contraseña? El problema es que si utilizamos hashes de 16 bits, tenemos un cambio razonable de no permitir una contraseña que no se usó anteriormente, pero que tiene el mismo hash de 16 bits. El ataque de cumpleaños muestra que para 16 bits, después de 36 contraseñas hay un 1% de probabilidad de que al menos una nueva contraseña sea rechazada --- esto puede o no ser aceptable. Más bits significa que esta oportunidad se reduce, pero la información expuesta por una base de datos pirateada se hace más grande.

^* Si sus contraseñas antiguas son "monkey1", "monkey2", "monkey3", es posible que un hacker aún pueda detectar este patrón. Por otro lado, dado que Google no requiere cambios de contraseñas mensuales, espero que las personas que usan patrones simples no se preocupen por cambiar su contraseña de Google en absoluto.

^** De nuevo, quiero dejar claro que no es más que una pista. La idea general de las contraseñas antiguas es que se han cambiado porque podrían haber sido comprometidas. Por lo tanto, el conocimiento de una contraseña antigua no es una sugerencia tan fuerte; probablemente querrán que escanees tu tarjeta de identificación o algo antes de restaurar el acceso. Sin embargo, sí agrega una primera capa de protección contra un niño de 16 años que intenta piratear la cuenta de un profesor o un script de computadora que intenta piratear muchas cuentas al mismo tiempo. 16 bits significarán que solo 1 de cada 64 k intentos de contraseña aleatoria pasan.

La mayoría de los comentarios aquí son bastante buenos e identifican los problemas clave. Sin embargo, uno El punto que debe tenerse en cuenta es que debe evaluar estos tipos de preguntas en contexto y tenga mucho cuidado con las generalizaciones que afirman que es bueno o malo.

Las preguntas del historial de contraseñas están relacionadas con el concepto de caducidad de contraseñas y requiriendo a los usuarios cambiar regularmente su contraseña. En un momento, fue reconocido las mejores prácticas para envejecer contraseñas y mantener un historial para garantizar que los usuarios no reutilicen un contraseña anterior Esto fue, en la mayoría de los casos, apropiado para los tiempos y Los ambientes más precisos de la época. Sin embargo, las cosas han cambiado y para muchos, ser forzado a cambiar regularmente su contraseña y prevenir su reutilización es de poco beneficio y posiblemente incluso detramental.

Ha habido algunas investigaciones que presentan la premisa de que el envejecimiento de las contraseñas y El historial de contraseñas puede disminuir la seguridad en lugar de aumentarla. Lo básico las suposiciones y las ideas son

• La mayoría de las personas solo tienen un número establecido de buenas contraseñas que son capaces de recordar
• Cuando se les obliga a cambiar su contraseña regularmente y se les impide reciclar las contraseñas, usan / patrones / para ayudar a que el requisito sea manejable
• Si puede obtener suficiente información del historial de contraseñas, identifíquelas los patrones pueden llegar a ser posibles. Esto no solo podría hacer el espacio de búsqueda para Adivinando una contraseña más pequeña, incluso podría permitir la predicción de contraseñas futuras.

Entonces, ¿esto significa que la contraseña y el historial son una mala idea? Posiblemente y posiblemente no. Depende del medio ambiente.

En mi vida privada, uso una gran cantidad de servicios web. Trato de adoptar el bien prácticas de contraseña: uso diferentes contraseñas en diferentes sitios, uso fuerte Las contraseñas y yo uso la verificación de dos factores cuando sea posible. No me comunico contraseñas sobre canales inseguros, etc. En este entorno, me veo forzado a cambiar mi Es poco probable que la contraseña y la imposibilidad de volver a utilizar una contraseña mejoren mi seguridad. Si el proveedor del servicio no está protegiendo esta información adecuadamente, Incluso podría estar reduciendo mi seguridad, ya que los atacantes pueden adivinar mi inteligente contraseña 'patrón'.

Por otro lado, una vez trabajé en un entorno donde muchos miembros del personal Viajó mucho y con frecuencia usaba redes desconocidas y posiblemente inseguras. En esto situación, había un riesgo mucho mayor de que una contraseña se ha comprometido. por En este caso, se puede justificar que los usuarios cambien sus contraseñas regularmente. ya que reducirá la superficie de ataque, es decir, la cantidad de tiempo en que un comprometido La contraseña puede ser utilizada por terceros no autorizados. Hacer cumplir el historial de contraseñas asegúrese de que el usuario no recicle una contraseña que ya haya sido comprometida. (En realidad, probablemente se obtendrían muchos más beneficios a través del usuario La educación y la enseñanza de las personas cómo reconocer redes posiblemente peligrosas y Permitiéndoles cambiar su contraseña cuando puedan evaluar con precisión los riesgos en lugar de que forzar una solución de un solo tamaño para todos, pero la educación y conciencia del usuario es una Nuez muy dura de romper!).

La medida en que el historial de contraseñas puede ser un problema de seguridad realmente depende de cómo Bueno, la historia está asegurada. El peligro es que la gente pueda pensar que porque es solo un historial de contraseñas pasadas, no requiere el mismo nivel de protección que los datos de la contraseña real requiere. Esto usualmente sería un error. La contraseña el historial debe tratarse con el mismo nivel de protección que la contraseña actual datos. Si esto se hace de manera efectiva, entonces probablemente no haya más riesgo que el hash de la contraseña real y, por supuesto, si los datos actuales de la contraseña actual no están adecuadamente protegido, entonces las preocupaciones sobre el historial de contraseñas probablemente sean irrelevantes.

Las contraseñas deben estar escritas con un algoritmo de extensión aprobado, como PBDKF2 o bcrypt. Además, deben combinarse con una sal única que luego se guarda con el hash. Dado que la sal es única, los ataques solo pueden ocurrir contra el hash dado y su sal.

Dado que la función de hash es computacionalmente prohibitiva (cuando se implementa correctamente), no se observan daños adicionales al mantener los hashes antiguos y las sales de las contraseñas anteriores.

Dado que se debe guardar un historial para asegurar las mejores prácticas de contraseña, entonces la única solución adecuada es guardar el hash y su sal, rotándolas a medida que el usuario actualiza sus contraseñas.