Almacenar contraseñas antiguas. Mala seguridad [duplicado]

4

Tengo un cliente que está convencido de que desea almacenar las últimas 4 contraseñas utilizadas para cada usuario y obligar a cada usuario a cambiar su contraseña cada 6 meses a algo que no se haya utilizado antes (es decir, no en los últimos 4 utilizados).

Les he aconsejado que no implementen ningún cambio de contraseña forzado por los siguientes motivos:

  1. Forzar a un usuario a cambiar un PW debilita la contraseña en el 90% de los casos, especialmente un cambio forzado que recuerda los últimos 4
  2. El almacenamiento efectivo de 5 hashes de contraseña (4 anteriores, 1 actual) para cada usuario podría ser una pesadilla si alguna vez se tratara de una violación de datos
  3. El sistema en cuestión ya tiene muchos otros controles de seguridad bien implementados, listas blancas de IP, etc.
  4. No forzar un cambio de PW está en línea con las últimas pautas de NCSC

Ahora les he explicado esto en detalle, pero todavía no verán el sentido.

Mi pregunta: ¿Es su otro ángulo que puedo tomar aquí? ¿Hay algún punto que haya perdido que ayude a mi caso?

NOTA: No estoy buscando técnicamente el almacenamiento de contraseñas antiguas, estoy tratando de convencer al cliente de que no implemente un cambio de contraseña forzado, y estoy tratando de construir el argumento más sólido posible.

    
pregunta Trickycm 17.09.2017 - 18:35
fuente

2 respuestas

4

Antes de hacer un esfuerzo por intentar que cambien, considere que podrían estar bajo un requisito que desconoce. Por ejemplo, si están usando estas contraseñas para acceder a un entorno de tarjeta de crédito, PCI DSS requiere un cambio de contraseña periódico. Esto podría ser algo completamente fuera de su control.

Si ese no es el caso, puede intentar remitirlos a las recomendaciones más recientes de NIST en SP 800-63B . En la sección 5.1.1.2 Verificadores de Secretos Memorizados (también conocidos como contraseñas), dicen esto [énfasis mío]:

  

Los verificadores NO DEBEN requerir que se cambien los secretos memorizados   arbitrariamente (por ejemplo, periódicamente). Sin embargo, los verificadores DEBERÁN forzar una   cambiar si hay evidencia de compromiso del autenticador.

La sección completa sobre contraseñas está pensada para ser leída e implementada en su totalidad, por supuesto, pero esta recomendación se mantiene por sí sola. La única queja que tengo en el documento es que su longitud mínima recomendada es de solo 8 caracteres, lo que claramente no es suficiente para resistir un ataque offline de fuerza bruta en los hashes de contraseña que pueden estar expuestos en una violación de datos. Para mitigar eso, requieren que los hash de contraseña almacenados estén suficientemente protegidos contra ataques de fuerza bruta, como 10,000 rondas de PBKDF2.

Se sugieren 10.000 rondas de PBKDF2 para la verificación de la contraseña en línea porque la idea es hacer que sea computacionalmente costoso verificar una sola contraseña, al tiempo que permite el procesamiento en tiempo real durante las frecuentes apariciones de inicios de sesión de usuarios. Pero tenga en cuenta que las confirmaciones de contraseñas antiguas solo se realizarían durante una actividad de cambio de contraseña real, lo que debería ocurrir con mucha menos frecuencia que los inicios de sesión regulares. Y esto abre una oportunidad para mejorar su seguridad.

Considere gastar potencia de procesamiento adicional durante el proceso de cambio de contraseña. Calcule el PBKDF2 (contraseña, 10000) y guárdelo en su tabla de "contraseña diaria", y mantenga un archivo de PBKDF2 (contraseña, 50000) en su tabla de "contraseña anterior". Cuando vuelvan a iniciar sesión, compárelos solo con la tabla de "contraseña diaria". Cuando cambien las contraseñas, realice la búsqueda en todas las entradas de la tabla de contraseñas anteriores; esto será mucho más lento que un inicio de sesión regular, pero debido a que es poco frecuente, no debería interrumpir su negocio normal. Una vez que se haya verificado que es único, descarte y reemplace el hash diario existente con el nuevo hash diario, y agregue el nuevo hash fuerte a la tabla de "contraseña anterior", deshaciéndose de su contraseña anterior más antigua.

Si al final no puede hablar de los cambios periódicos de contraseña, intente que al menos implementen el almacenamiento práctico más sólido de "contraseñas anteriores".

    
respondido por el John Deters 17.09.2017 - 23:28
fuente
2

Otro punto que no ha considerado es que la seguridad general de su contraseña se encuentra en su punto más vulnerable durante un cambio de contraseña. Sin considerar la seguridad de los sistemas, este es un momento en que un ataque de ingeniería social o de caballo de Troya puede engañar a los usuarios. Las rotaciones forzadas aumentan tu superficie de ataque. Este es el riesgo de equilibrar una contraseña que se roba hoy y se usa incorrectamente uno o dos años más tarde.

    
respondido por el John Deters 18.09.2017 - 15:01
fuente

Lea otras preguntas en las etiquetas