¿Cuánto cuenta la iteración de PBKDF2 desconocido para mejorar la seguridad?

No agregaría suficiente seguridad para importar. Solo significa que el atacante debe comparar con el hash almacenado después de cada iteración de la función PBKFD2, en lugar de una vez después del conteo (conocido). Dado que una comparación es mucho más rápida que una iteración (para cualquier función hash subyacente razonable), esto no ralentiza significativamente al atacante.

Un problema ligeramente más sutil es que el atacante tiene que jugar juegos de adivinanzas prioritarios con dónde invertir sus ciclos. Si ha ejecutado su diccionario básico de contraseñas a través de 1,000 iteraciones y no ha recibido ninguna respuesta, ¿debería ir a un diccionario más grande o extenderse a 2,000 iteraciones? En la práctica, probablemente alternará las expansiones de búsqueda hasta que reciba un golpe. Tenga en cuenta que si su programa de búsqueda está escrito para admitir esto (no sé si lo hay, pero ciertamente es posible y el código fuente está disponible), puede guardar todos los resultados intermedios después de, por ejemplo. 1,000 iteraciones, así que cuando se extiende a 2,000 iteraciones, solo está haciendo el cálculo para otras 1,000 iteraciones.

Tan pronto como el atacante encuentre una coincidencia (la contraseña más débil en la base de datos), inmediatamente adivinará que todas las demás contraseñas tienen el mismo recuento, y regresa al ataque estándar. (Tenga en cuenta que si varía los recuentos entre cuentas, tendrá que almacenar el recuento junto con el hash, lo que significa que cuando robe la base de datos de hash también tendrá los recuentos y todo esto es discutible).

Por cierto, el término general para cosas como esta (elementos secretos del algoritmo hash que son iguales para todos los usuarios y, por lo tanto, no es necesario almacenarlos junto con los hashes) es "pimienta". Es un concepto útil (siempre que tenga una forma de almacenar el valor de la pimienta que no solo se robará junto con los hashes), pero esta no es una buena manera de inyectar la pimienta en el algoritmo hash.

Un recuento de iteraciones ocultas no agregará mucho a la seguridad, por dos razones:

• El sistema que normalmente usa PBKDF2, por ejemplo. Para descifrar el archivo, debe conocer el recuento de iteraciones. Puede filtrarse, por ejemplo. midiendo el tiempo que tarda ese sistema en procesar un archivo entrante; por lo que podría no ser tan secreto como eso. Además, es poco probable que el recuento de iteraciones se considere como parte de la contraseña, más bien como parte de configuración : se escribirá en un archivo de configuración, tal vez se defina en un documento de especificaciones, o se intercambie a través de correos electrónicos ... Por el contrario, si todas las partes consideran que el recuento de iteraciones es parte de la contraseña y está protegido como tal, entonces se logrará una seguridad al menos tan buena (y probablemente mejor) simplemente añadiendo ese recuento a la contraseña (como un cadena).

• Si observa PBKDF2 , verá que al calcular la salida para el recuento de iteraciones c también implica calcular la salida para los recuentos de iteración c-1 , c-2 ... obtienes todos estos "gratis" ya que esto es solo un gran XOR entre muchos valores pseudoaleatorios, y ninguno de ellos depende del número previsto de iteraciones (podría haber sido de otra manera, pero PBKDF2 se definió de esa manera). Probar una salida PBKDF2 es menos costoso en promedio que calcular la siguiente iteración: una iteración de PBKDF2 / SHA-1 para una salida de 256 bits conlleva dos llamadas HMAC / SHA-1, por lo tanto cuatro invocaciones SHA-1, mientras que "probar" "una clave significa descifrar el primer bloque con AES-256 y ver si el resultado tiene sentido; intentar una clave AES-256 es menos costoso que calcular un SHA-1 elemental, y mucho menos cuatro SHA-1 elemental. De ello se deduce que "ocultar" el recuento de iteraciones ralentizará un ataque de fuerza bruta en un máximo del 25%, lo que no es nada sorprendente.