¿Por qué elegirías disminuir el cálculo de un hash de contraseña?
¿Por qué elegirías disminuir el cálculo de un hash de contraseña?
El cálculo se ralentiza intencionalmente para que sea más difícil para un atacante forzar con fuerza las contraseñas de los usuarios en caso de que la base de datos de contraseñas sea robada, por ejemplo.
Debido a que una función de hash solo funciona "de una manera", para obtener la contraseña de un hash, debe hashear contraseñas aleatorias hasta que encuentre una con un hash correspondiente. ( las tablas Rainbow proporcionan una compensación).
Usando GPU es posible brute-force billions de e.g. MD5 hashes por segundo.
Es por eso que funciones hash como bcrypt o scrypt se desarrollaron para mitigar este problema ejecutándose lentamente y en caso de que Scrypt requiera mucha memoria, no es factible calcular el hash mediante GPU.
Para su aplicación "normal" es muy probable que esto todavía sea lo suficientemente rápido, ya que solo está calculando un solo hash, por lo que el impacto en el rendimiento será insignificante.
Posiblemente lo que te está desconcertando es que no está más claro que ... el cálculo no se ralentiza en absoluto.
Esto es: no hay una forma "más rápida" que se ignore a propósito (no que sepamos); no hay "espera" artificial en el algoritmo.
Más bien, el cálculo está diseñado para ser lento . O la memoria intensiva. O mejor aún, ambos. No hay camino, excepto el largo y sinuoso para obtener el resultado.
De esta manera, el cálculo uno (el de la contraseña correcta) sigue siendo muy, muy rápido. Para los usuarios honestos, nada cambia perceptiblemente. Una décima de segundo o una mil millonésima de segundo no parece diferir demasiado.
Pero los cálculos de mil millones (aquellos para encontrar cuál es la contraseña correcta entre mil millones de candidatos, y en realidad hay muchos, muchos más) serán terriblemente lentos, garantizando que una "fuerza bruta" La verificación de todas las contraseñas posibles está condenada al fracaso.
Entonces, si tenemos un algoritmo de hash que es demasiado rápido, no requerimos su primera iteración, sino su millonésima parte. si es seguro . Esperemos que no haya ninguna forma (que sepamos) de saltar directamente al resultado número un millón; Tienes que calcularlos todos . Y si esto no se puede hacer, decimos que el algoritmo no es seguro (suficiente).
Los hashes de contraseña están diseñados para ser un cálculo computacionalmente lento porque, en caso de que se filtren los hash de contraseña, se puede ralentizar significativamente a un atacante que intenta encontrar la contraseña de texto simple.
Si el hash de la contraseña es lento de calcular, hace que forzar bruta una contraseña sea mucho más lenta, lo que se acumulará en un conjunto de datos grande o un número de conjeturas. Si demora mucho más tiempo, ganas ese tiempo extra para hacer frente a la infracción.
Con él, puedes agregar una dureza lineal a los ataques del diccionario. Es decir. aplicando un complejo algoritmo de salado, puede hacer que la necesidad de cálculo de los ataques del diccionario sea n veces mayor. Por ejemplo, puedes hacerlo 1000 veces más grande.
En el sentido algorítmico, no es muy útil, porque como podemos ver, la potencia de cómputo crece principalmente exponencialmente con el tiempo. Pero sigue siendo una capa adicional de seguridad.