He estado buscando la respuesta, pero la última que encontré estaba desactualizada por tres años. Entonces, ¿cuáles son los factores de costo de scrypt recomendados para 2016?
En general, use el factor de costo máximo que es soportable desde una perspectiva de rendimiento. Yo crearía una aplicación de referencia que sea lo más cercana posible a lo que hace su aplicación y descubriría el factor de costo en su hardware de producción que le brinda el máximo retardo tolerable.
En la mayoría de los sistemas, me esfuerzo por un retraso de 10 a 20 ms. Supongamos que su atacante tiene un hardware que es, digamos, 1000 veces más poderoso que el suyo (lo que no es irrazonable, dado que Scrypt no puede ser acelerado por la GPU), puede probar 10 5 conjeturas por segundo. Para una contraseña alfanumérica de 10 caracteres, son 26 contraseñas de 10 , o aproximadamente 10 14 posibles conjeturas. Eso llevaría 10 segundos 9 , o 31 años. Suena aceptable para mí.
Si desea utilizar retrasos aún mayores, recuerde que scrypt es difícil de almacenar. Esto significa que utiliza una gran cantidad (relativa) de memoria, en el orden de megabytes, para cada verificación, por lo que tener una gran cantidad de ellos ejecutándose en paralelo puede ser más un golpe de rendimiento que la potencia de procesamiento absoluta requerida.
Echa un vistazo a Security.stackexchange.com "¿Cantidad recomendada de iteraciones al usar PKBDF2-SHA256?" para un buen análisis del mismo tema en PBKDF2.
Lea otras preguntas en las etiquetas passwords password-management hash scrypt