¿Cantidad recomendada de iteraciones al usar PKBDF2-SHA256?

Debe utilizar el número máximo de rondas que sea tolerable, en lo que respecta al rendimiento, en su aplicación. El número de rondas es un factor de desaceleración, que se usa sobre la base de que en condiciones de uso normales, dicha desaceleración tiene un impacto insignificante para usted (el usuario no lo verá, el costo adicional de la CPU no implica la compra de un servidor más grande y pronto). Esto depende en gran medida del contexto operacional: qué máquinas están involucradas, cuántas autenticaciones de usuarios por segundo ... así que no hay una respuesta única para todos.

La imagen amplia va así:

• El tiempo para verificar una sola contraseña es v en su sistema. Puede ajustar este tiempo seleccionando el número de rondas en PBKDF2.
• Un atacante potencial puede reunir f más potencia de CPU que usted (por ejemplo, tiene un solo servidor y el atacante tiene 100 PC grandes, cada uno dos veces más rápido que su servidor: esto lleva a < em> f = 200 ).
• El usuario promedio tiene una contraseña de bits de entropía n (esto significa que al intentar adivinar una contraseña de usuario, con un diccionario de "contraseñas plausibles", tomará en promedio 2 ^n-1 intenta).
• El atacante encontrará que vale la pena atacar su sistema si la contraseña promedio se puede descifrar en un tiempo inferior a p (esa es la "paciencia" del atacante).

Tu objetivo es hacer que el costo promedio de romper una sola contraseña exceda la paciencia del atacante, de modo que ni siquiera lo intente, y se concentre en otro objetivo más fácil. Con las anotaciones detalladas anteriormente, esto significa que desea:

v · 2 ^n-1 > f · p

p está fuera de su control; se puede estimar con respecto al valor de los datos y sistemas protegidos por las contraseñas de los usuarios. Digamos que p es un mes (si lleva más de un mes, el atacante no se molestará en intentarlo). Puede hacer f más pequeño comprando un servidor más grande; por otro lado, el atacante intentará agrandar f comprando máquinas más grandes. Un punto agravante es que el descifrado de contraseñas es una tarea vergonzosamente paralela , por lo que el atacante obtendrá un gran impulso al usar una GPU que admite la programación general ; por lo tanto, un f típico todavía variará en el orden de unos pocos cientos.

n se relaciona con la calidad de las contraseñas, que de alguna manera puede influir a través de una estricta política de selección de contraseñas, pero en realidad tendrá dificultades para obtener un valor de n más allá, digamos, 32 bits. Si intenta imponer contraseñas más seguras, los usuarios comenzarán a luchar activamente contra usted, con soluciones alternativas, como reutilizar contraseñas de otros lugares, escribir contraseñas en notas adhesivas, etc.

El parámetro restante es v . Con f = 200 (un atacante con una docena de GPU buena), una paciencia de un mes y n = 32 , necesita v para tener al menos 241 milisegundos (nota: inicialmente escribí "8 milisegundos" aquí, lo cual es incorrecto: esta es la cifra para una paciencia de un día en lugar de un mes). Por lo tanto, debe establecer el número de rondas en PBKDF2, de modo que computarlo con una sola contraseña lleve al menos tanto tiempo en su servidor. Aún podrá verificar cuatro contraseñas por segundo con un solo núcleo, por lo que el impacto de la CPU es probablemente insignificante (*). En realidad, es más seguro usar más rondas que eso, porque, seamos realistas, obtener un valor de 32 bits de entropía de la contraseña de usuario promedio es un poco optimista; por otro lado, no muchos ataques dedicarán decenas de PC durante un mes completo a la tarea de descifrar una sola contraseña, por lo que tal vez una "paciencia del atacante" de un día sea más realista, lo que lleva a un costo de verificación de contraseña de 8 milisegundos.

Entonces necesitas hacer algunos puntos de referencia. Además, lo anterior funciona siempre y cuando su implementación de PBKDF2 / SHA-256 sea rápida. Por ejemplo, si utiliza una implementación totalmente basada en C # / Java, obtendrá el típico factor de ralentización de 2 a 3 (en comparación con C o ensamblaje) para tareas que requieren un uso intensivo de la CPU; en las anotaciones anteriores, esto es equivalente a multiplicar f por 2 o 3. Como base de comparación, una CPU Core2 de 2.4 GHz puede realizar aproximadamente 2.3 millones de cálculos SHA-256 elementales por segundo (con una sola núcleo), por lo que esto implicaría, en esa CPU, aproximadamente 20000 rondas para lograr el objetivo de "8 milisegundos".

(*) Tenga cuidado de que hacer que la verificación de la contraseña sea más costosa también hace que su servidor sea más vulnerable a Denial-of-Service ataques . Debe aplicar algunas contramedidas básicas, tales como listas negras de direcciones IP de clientes que envían demasiadas solicitudes por segundo. Debes hacerlo de todos modos, para frustrar los ataques del diccionario en línea .

Ejecute openssl speed en la línea de comandos para tener una idea de qué tan rápido son las funciones de resumen de mensajes. Puedo calcular aproximadamente 1,6 millones de sha256 hash por segundo o aproximadamente 145 Billion por día en mi puente de arena de 2,2 gHz de cuatro núcleos. Si alguien tiene una contraseña que está en el diccionario de inglés y usó una ronda de sha256, entonces tomaría más tiempo cargar la lista de palabras del disco que iterar sobre la lista para romper el hash. Si hiciera PKBDF2-SHA256 con unos pocos cientos de miles de rondas, tomaría unos pocos minutos para romper. Hacer cumplir una política de contraseña segura ayuda, mucho .

La respuesta real: ¿Cuánto tiempo tienes para quemar?

La respuesta de Thomas proporciona un modelo y datos de referencia útiles. Pero el objetivo que él plantea no tiene sentido para mí. Un atacante típico no sabrá su recuento de iteraciones hasta que realmente haya pirateado el sitio y haya tomado la base de datos de hashes. Una vez hecho esto, no se moverán solo porque usas una gran cantidad de iteraciones. Intentarán descifrar todos los que puedan y, posiblemente, darán a conocer los hashes para que otros sigan intentando descifrarlos durante muchos años con un hardware más potente. Por lo tanto, "p" y "f" seguirán aumentando mucho después del hackeo.

Además, las contraseñas de usuarios reales no están bien modeladas por una medida de complejidad como 32 bits de entropía. El artículo Seguridad reutilizable: Nuevo documento sobre las métricas de seguridad de contraseña es es útil en este sentido, y documenta lo que hemos sabido por mucho tiempo: muchos usuarios escogen contraseñas fáciles de adivinar, y hay una larga cola. Esto también significa que los atacantes siempre encontrarán algunos si se esfuerzan lo suficiente.

Yo diría que un objetivo más probable sería proteger un porcentaje tan alto de sus usuarios como sea posible para que no se agrieten sus contraseñas. P.ej. la tabla 4.2.1 de PDF muestra que si logró limitar a su atacante durante una campaña de ataque de un promedio de 1 millón de intentos por hash down Para 500,000 intentos, puede proteger las contraseñas del 5% de sus usuarios (suponiendo una combinación con más de 7 caracteres que de 8 o más caracteres, reduciendo así el porcentaje de grietas del 35% al 30%). Por supuesto, la forma exacta de la curva y su ubicación variarán ampliamente.

Por lo tanto, me gustaría ir al recuento de iteraciones máximo para el que puede realizar el presupuesto, siempre y cuando no demore a los usuarios reales haciendo inicios de sesión normales. Y debe aumentar el valor a medida que su capacidad de cómputo aumenta con los años.

Una máquina moderna equipada con 8 GPU de la generación actual calculará el orden de 9 mil millones de hashes SHA-256 por segundo, o aproximadamente 777 trillones de hashes por día, y esas GPU pueden realizar ataques de diccionario basados en reglas.