¿Re-saltar contraseñas regularmente aumentaría / disminuiría la seguridad?

Las colisiones de la función de hash no son relevantes para el hashing de contraseñas. Todo el hashing de contraseñas funciona en la resistencia de preimagen, no en las colisiones. Puede olvidarse de todas las colisiones cuando se habla de hash de contraseñas.

Salt las "colisiones" pueden importar pero se llaman mejor "reutilización de sal". Evita la reutilización de la sal utilizando sales aleatorias suficientemente grandes (16 bytes son suficientes; GUID son buenas sales).

No puedes cambiar el salt sin tener acceso a la contraseña. Si pudieras hacerlo, entonces el atacante también podría hacerlo, y anular los beneficios de las sales. Esto sería una seria debilidad de la función hash.

No tiene sentido cambiar la sal. El valor agregado de la sal único es en qué se diferencia de otros valores de sal. No hay ganancia en reemplazar un valor de sal con otro valor; puede haber una pérdida neta si el nuevo valor es igual a otro valor de sal, lo que lleva a la reutilización de sal.

Es decir, cuando utiliza sales aleatorias, está asegurando la ausencia de reutilización de sal heurísticamente: si alguna vez genera sales de s , en un espacio de tamaño n (por ejemplo, < em> n = 2 ¹²⁸ para sales de 16 bytes aleatorias), entonces el riesgo de reutilización de sal permanece bajo siempre que s ² es pequeño con respecto a n . Básicamente, con sales de 16 bytes, elegidas al azar de un buen PRNG , tiene espacio para aproximadamente 2 ⁶⁴ instancias de generación de sal. Si cambia las sales con regularidad, más a menudo de lo estrictamente requerido, entonces está incrementando s , es decir, disminuyendo su espacio para respirar. Afortunadamente, 2⁶⁴ es un número enorme, por lo que suponiendo que haga todo lo demás correctamente, luego reemplace las sales cada semana (cuando el usuario inicia sesión, porque no puede hacerlo sin la propia contraseña) no implicará un riesgo adicional significativo. Será inútil, pero inofensivo.

Si, a partir de varios valores hash con varias sales y la misma contraseña, el atacante puede calcular la propia contraseña o reducir su espacio clave (con mayor éxito que el simple riesgo de reutilización de sal explicado anteriormente), entonces esto es un criptográfico. debilidad de la función de hashing de contraseña. No se conoce tal debilidad por las funciones de hash de contraseña habituales (bcrypt, PBKDF2 ...).

Como lo señaló Tom Leek anteriormente, no tiene sentido resaltar si usas un hash salado "simple".
Lo que no deberías hacer, dado que las plataformas con una docena o más de GPU pueden dañar la fuerza en decenas a cientos de miles de millones [1] de hashes por segundo en la actualidad, y no puede esperar que una contraseña de usuario tenga mucho más de 30-40 bits de entropía (si tiene mucha suerte ). 40 bits es de 10.9 segundos a 100 G / s.

Sin embargo, puede aumentar la seguridad "haciendo resaltes", si (con suerte) utiliza un esquema de derivación / estiramiento de clave lenta como scrypt o PBKDF2 en lugar de un simple hash salado.

En lugar de (por ejemplo) 1,000 iterations, haría 1,000+N iterations, e incrementaría N después de un inicio de sesión exitoso, con un límite de tasa (por ejemplo, una vez por día como máximo).
De esa manera, debe realizar un seguimiento de un valor adicional ( N ) por usuario, pero puede actualizar ("resaltar") la contraseña con hash casi de forma gratuita, utilizando una única iteración adicional, y sin tener que conocer la contraseña original. !
Tenga en cuenta que la sal no se modifica técnicamente (aunque podría si quisiera, por ejemplo, si agregó N a la sal) pero es el mismo resultado neto que usar una sal diferente, ya que el número de Las iteraciones son diferentes.

También sería posible aumentar N en el número de días desde el último inicio de sesión (si realiza un seguimiento de eso), por lo que los usuarios que solo inicien sesión una vez por semana o una vez cada dos semanas tendrán un promedio de El mismo margen de seguridad.

El esfuerzo computacional de la función de derivación de claves se adapta con el tiempo, lo que explica que el hardware de craqueo más rápido se vuelva más barato con el tiempo. Las iteraciones 1,000 se convierten en iteraciones 1730 después de dos años. El costo de actualizar todos los hash en la base de datos se amortiza en los inicios de sesión y es muy bajo (prácticamente cero).