Si los usuarios proporcionaron contraseñas aleatorias con el equivalente de más de 128 bits de entropía que nunca se usan en otros lugares, no hay necesidad de una función hash lenta como bcrypt, scrypt, sha256crypt, sha512crypt o PBKDF. Del mismo modo, no habría necesidad de una sal en el hash.
¿Por qué? La fuerza bruta es simplemente inviable cuando el tiempo esperado es O (2 128 ); por ejemplo, incluso con miles de millones de computadoras que prueban miles de millones de hashes por milisegundo, no podrá hacer fuerza bruta en un hash de entropía de 128 bits en millones de años (precisamente tendría una posibilidad de 1 en 10000 de romperlo). Por supuesto, no hay un método confiable para probar la fortaleza de las contraseñas creadas por el usuario, ya que la entropía depende en gran medida del modelo. Por ejemplo, una contraseña como: Qwertyuiopasdfghjklzxcvbnm
aparecerá como 132 bits a pesar de ser el orden de las teclas del teclado y es bastante baja entropía. O si mi contraseña para security.stackexchange.com era https://security.stackexchange.com
, la calculadora dice 147 bits de entropía (cuando está extremadamente débil). Por otro lado, si conoce el método de generación de contraseñas, puede calcular de manera confiable la entropía de las contraseñas; por lo tanto, si obliga a todos sus usuarios a aprender una contraseña aleatoria de 128 bits que generó, puede asegurarse de que sus contraseñas sean razonablemente sólidas.
Sin embargo, aún se necesitaría una función hash, ya que nunca deberías almacenar contraseñas en texto plano. Un atacante no debería poder encontrar una lista de contraseñas de texto sin formato en la base de datos de algún otro compromiso (por ejemplo, encontrar una copia de seguridad antigua, inyección de SQL, pérdida de memoria, etc.). Un hash simple (por ejemplo, SHA-2) funcionaría para evitar eso.