Copié y pegué una función que implementa el algoritmo de hash PBKDF2 en PHP. La función solicita la cantidad de tiempo que quisiera que hiciera un ciclo para producir un hash.
Ahora, me pregunto, cuál sería un recuento de iteraciones razonablemente alto que garantice un hash muy seguro, mientras que al mismo tiempo no hace que el servidor se ralentice a un rastreo.
Así que la sabiduría de Wikipedia es que 1,000 iteraciones fue el número esperado en el año 2,000. La ley de Moore dice que el poder se duplica cada 18 meses. Eso hace que (aww, no podemos usar MathJAX aquí) 2 ^ (11 / 1.5), o aproximadamente un factor de 160. Según esa teoría, deberías usar algo en el estadio de 160.000 iteraciones.
... pero en realidad, solo haz un punto de referencia. Calcule cuántos inicios de sesión por segundo desea que su servidor maneje y establezca su número de iteraciones en consecuencia. Recuerde que puede aumentar el número de iteraciones a lo largo del tiempo más fácilmente de lo que puede reducirlas (reducción solo en el inicio de sesión), por lo que debe tomar un poco de forma conservadora.
Bueno, lo dijiste. El recuento correcto es exactamente el recuento que "no hace que el servidor se ralentice a un rastreo". Desea que sea tan alto como sea posible, dado el hardware que utiliza y la carga promedio esperada. Como dijo @Jeff, esto es una cuestión de referencia.
Todo el concepto consiste en hacer que el proceso de hashing de contraseñas sea lento para el atacante. Esto hace que sea lento para todo el mundo, incluido usted, por lo que no puede hacerlo como desearía. El principio de funcionamiento aquí es que su noción de costo, y la del atacante, no son exactamente proporcionales: un aumento de costo de 1000x es "gratuito" para usted si significa que gastará 1 ms en lugar de 1µs para autenticar a un usuario, mientras que convertir un ataque de 1 hora en un ataque de 6 semanas ciertamente no es no gratuito para el atacante.