Tu punto de partida

  

PBKDF2-HMAC-SHA-256

     

número de iteraciones deseadas = 1024

     

longitud de la sal en bytes = 16

     

longitud de la clave derivada en bytes = 4096

Algoritmo

Ok - PBKDF2-HMAC-SHA-256 es una opción sólida, aunque si está ejecutando cualquier CPU moderna de 64 bits, recomendaría PBKDF2-HMAC-SHA-512 en su lugar, porque SHA-512 requiere 64 Operaciones de bits que reducen el margen de la ventaja de un atacante basado en GPU, ya que las GPU modernas tampoco funcionan en 64 bits.

Sal

16 bytes de sal están bien, siempre que sean criptográficamente aleatorios y únicos por contraseña. Las recomendaciones normales están en el rango de 12-24 bytes, con 16 consideradas bastante sólidas.

Salida e iteraciones

4096 bytes de salida es ¡MUCHO ACTIVAMENTE! SHA-256 tiene un tamaño de salida nativo de 32 bytes. PBKDF2 / RFC2898 indica que en este caso, primero ejecutará 1024 iteraciones para obtener la primera (la más a la izquierda) 32 bytes, luego otras 1024 iteraciones para los siguientes 32 bytes, y así sucesivamente 128 veces en total para obtener los 4096 bytes completos de salida que solicitó.

Entonces, hiciste 131072 iteraciones en total y obtuviste 4096 bytes de salida. El atacante realizará 1024 iteraciones en total y comparará sus 32 bytes de salida con los primeros 32 bytes (más a la izquierda) de su salida. Si esos son los mismos, ¡adivinaron correctamente! ¡Acabas de darle a cada atacante una ventaja de 128: 1!

En cambio, si está satisfecho con la velocidad, debe hacer 131072 iteraciones con 32 bytes de salida; pasará la MISMA cantidad de tiempo que está ahora (¡así que es gratis!), y sus atacantes deberán pasar ¡128 veces más tiempo que ahora!

• NOTA: si se muda a PBKDF2-HMAC-SHA-512, puede usar hasta 64 bytes de salida, y cada iteración durará un poco más.

Nunca obtenga más salida para el hash de contraseña que la salida nativa de su función hash, es decir, 20 bytes para SHA-1, 32 para SHA-256, 64 para SHA-512. Opcionalmente puede almacenar menos, pero no le ahorra ningún cálculo. Recomendaría almacenar al menos 28 bytes de salida (224 bits, que es el doble de 112 bits, la seguridad nominal de 3DES).

Tenga en cuenta que los valores de longitud de salida son pura salida binaria: ANTES DE BASAR 64 o de hexificarlos, si lo hace (personalmente, almacenaría el binario sin formato; usa menos espacio y requiere una conversión menos).

Mi primera sugerencia es utilizar el mecanismo de almacenamiento de contraseña predeterminado de su plataforma. Funciones como password_hash de PHP eliminan todas las preocupaciones y problemas del almacenamiento de contraseñas.

Suponiendo que no puedes hacer eso, recomiendo usar bcrypt, o tal vez incluso las funciones scrypt más nuevas. bcrypt es más difícil de descifrar cuando se utilizan operaciones paralelas en una GPU. Scrypt grava la memoria así como la CPU. Esta respuesta explica que todo esto es un gran detalle.

Suponiendo que estás atascado con pbkdf2 por cualquier razón ...

Salt: Según esta respuesta de 2013 por Thomas Pornin, de 128 bits o 16 bytes es suficiente. Las recomendaciones de Crackstation son 192 bits o 24 bytes. Creo que cualquier lugar en ese rango es seguro. Personalmente, aceptaría los 24 bytes, ya que la longitud de sal (suponiendo que no se cuelga al generar datos aleatorios) no contribuye realmente al rendimiento del hash. Asegúrese de usar un CSPRNG para generar la sal.

Longitud de la contraseña: la respuesta de Thomas Pornin recomienda 12 bytes, Crackstation 24. De nuevo, tiendo a ir con el tamaño más grande, pero creo que cualquier cosa dentro de ese rango es segura.

Iteraciones: El número de iteraciones debe ser el máximo posible. Así que empieza a probar el rendimiento del hashing. He visto recomendaciones para 0.05-0.10 segundos, pero creo que esas son solo estimaciones. Si tiene recursos computacionales de sobra, quizás pueda subir un poco más (demasiado alto hará que la autenticación sea demasiado lenta). Si tienes pocos recursos computacionales, ve más pequeño.

Summary:

number of iterations desired        = max you can tolerate
length of the salt in bytes         = 16-24
length of the derived key in bytes  = 12-24

1. 8 bytes de sal está bien, porque es globalmente único cuando se genera aleatoriamente, y ese es el propósito de una sal: unicidad. Demasiado grande no es un problema, por lo que estimar en la parte alta está bien, excepto que desperdicia un poco de almacenamiento.

2. 32 bytes sería bueno para una longitud de clave derivada (la mayoría de los algoritmos de hashing generarán entre 16 y 64 bytes, donde 64 es un exceso). Su valor de 4096 es definitivamente excesivo. ¡Espero que haya confundido bytes con bits allí!

3. Las iteraciones son muy simples: tantas como sea posible en su hardware. Si un inicio de sesión puede tardar hasta medio segundo, evalúe cuántas iteraciones puede hacer antes de que pase medio segundo. En 2018, 300 000 es un valor razonable para un servidor de baja potencia (las CPU de gama alta pueden manejar más iteraciones).

Si está ejecutando en un sistema con poca potencia (por ejemplo, Raspberry Pi), es posible que desee considerar un hardware diferente según la seguridad de las cosas, o hacer que el inicio de sesión tarde más tiempo. El inicio de sesión se realiza normalmente solo una vez al día o algo así, por lo que esperar 10 segundos puede ser razonable dependiendo de sus objetivos.