El RFC no especifica, pero creo que si estos valores estuvieran disponibles, podrían ayudar al atacante.
Por ejemplo, para scrypt, si el parámetro de tamaño de bloque r , el parámetro de costo de CPU / memoria N , y el parámetro de paralelización p están disponibles, el ataque sabrá qué valores usar cuando se ejecute la fuerza bruta.
¿Alguna idea?
Yo diría que los parámetros de costo cuentan como "detalles de la implementación" y confiar en ellos estando ocultos sería, por lo tanto, seguridad a través de la oscuridad .
Mantenerlos en secreto de forma activa sería como usarlos como una especie de pimiento de baja entropía. No enteramente inútil, pero casi. Además, si un atacante logra descifrar una contraseña, sabrá los factores correctos. Así que simplemente intente password1 con algunos factores diferentes en todas las contraseñas, y listo. Si desea un secreto adicional para proteger las contraseñas, simplemente use un pimiento común o cifre los hashes. Esas son soluciones que intentan resolver este problema.
Eso no significa que deba revelarlos a todo el mundo a menos que tenga una razón para hacerlo. Claro, si quieres decirle a alguien que presuma sobre lo seguro que es tu sistema, sigue adelante. Pero no lo pondría en mi página web, especialmente si fueran bajas ya que eso podría alentar a los atacantes. (Por otro lado, decir "usamos bcrypt" es como poner un letrero de "cuidado con el perro" en tu cerca).
La mayoría de las personas usa uno de los pocos conjuntos de factores de costo. Lo alentaría a elegir los factores de costo en función de lo que es bueno para su sistema y no de lo que es difícil de adivinar.
Tenga en cuenta que el factor de costo está justo ahí en el hash, por lo que necesitaría cortarlo activamente de la cadena para implementar esto. Pero no me molestaría.
Pregunta relacionada: ¿Puedo compartir qué función hash de contraseña usé en un informe público?