Historial de contraseñas con PBKDF2

¿De dónde viene el requisito de los "15 anteriores"? Parece poco probable que la seguridad mejore mucho, mi primer paso sería reducir eso si no proviene de un requisito legal, regulatorio, de la industria o de auditoría.

• Un atacante que realiza un ataque en línea no se dará cuenta en absoluto
• Un atacante con su base de datos de PW que realice un ataque sin conexión solo contra las contraseñas actuales no le importará durante el ataque
• El análisis más complejo de la detección de patrones en la parte de los atacantes es demasiado complejo para entrar aquí, pero imagina a un usuario que usa football1, luego football10, football100, etc. El patrón es obvio si tienes algunas contraseñas, incluso si football100000000 pudiera no se debe intentar hasta que se llegue a una etapa muy tardía de adivinar la contraseña (en caso de que sea así, dados los cientos de miles de iteraciones que debe usar)

También tenga en cuenta que probar N diferentes valores PBKDF2 a la vez significa que puede usar múltiples núcleos; es decir, para 15 PBKDF2 se ejecuta a 1 s cada uno, si tenía 10 núcleos, esto podría tomar tan poco como 2 segundos (10 en el primer segundo, 5 en el segundo segundo). Sin embargo, utilizarás el mismo (o algo más) tiempo de CPU, ten cuidado.

Reducir significativamente el tiempo de ejecución de PBKDF2 disminuye la seguridad, ya que el atacante tiene que hacer menos trabajo en la misma proporción en que trabajas menos. Si puede permitirse destinar 1s de tiempo de CPU (presumiblemente para inicios de sesión bastante infrecuentes, o para una granja de servidores muy hoss), ¡guárdelo! Eso aumentará dramáticamente la carga de trabajo de un atacante al mismo nivel que reduce la suya; No lo recomiendo.

Si está apuntando a un segundo de trabajo PBKDF2 por inicio de sesión, entonces 15 usuarios que inician sesión aproximadamente al mismo tiempo son exactamente la misma carga de trabajo que otras 15 operaciones únicas de PBKDF2 de sal: asegúrese de poder pagar sus tiempos objetivo actuales en su carga máxima esperada para los próximos 2-3 años. Además, ¿con qué frecuencia los usuarios cambiarán sus contraseñas?

Otra alternativa:

• No cambie la sal de un usuario cada vez.
  • Esto es no una gran idea, pero se puede hacer y resolverá su problema de rendimiento. Sin embargo, los atacantes sin conexión con la lista completa de contraseñas tendrán 16 veces más posibilidades de adivinar contraseñas para cada intento.
  • Solo cambiando la sal cada 2 a 6 los cambios de contraseña tendrían un término medio. Sería menos malo si tienes cambios de contraseña muy frecuentes.

P.S. Sabes que vas a obtener usuarios usando P @ $$ w0rd1, P @ $$ w0rd2, P @ $$ w0rd3, P @ $$ w0rd ..., P @ $$ w0rd999, ¿no?

Qué te parece esto: cuando cambias las contraseñas, solicita la contraseña antigua (lo haces de todos modos, ¿verdad?) y luego, además de las pruebas para ver si la contraseña anterior coincide, TAMBIÉN vuelve a codificar la contraseña antigua con una sola iteración. Ya que ya no es válido, no te importa mucho lo fácil que es descifrarlo (porque descifrarlo no ayuda mucho al atacante). Y luego almacena la versión hash rápida en tu historial.

En ocasiones, es posible que no obtenga la contraseña anterior (por ejemplo, si un administrador la modificó), por lo que es posible que desee colocar un marcador en el campo de contraseña anterior para indicar cómo se ha activado, de esa manera su sistema es compatible con ambas variaciones.

Lo que Travis no dijo fue cuál era el propósito general de usar las contraseñas antiguas en primer lugar. Quiero decir, la auditoría puede requerirlo, pero nadie dice POR QUÉ es necesario. Probablemente sea una mala idea. En general, no aumentará la seguridad, e incluso aparte de los problemas de rendimiento, corre el riesgo de reducir significativamente la seguridad si no se hace correctamente. Es mucho más probable que se haga incorrectamente que de forma adecuada.