Primero, MD5 tiene otros problemas además de las rápidas velocidades de hash, incluyendo vulnerabilidades de colisión .
Una vez que las computadoras se vuelvan más rápidas, estas no serán mejores que md5.
Así que me pregunto si es posible tener una función hash que sea
¿Seguro, independientemente del tiempo que lleve ejecutarse?
No, una función hash en sí misma siempre podría ser dañada usando una computadora suficientemente rápida (lo suficientemente rápida como la ambigua bala de plata). Sin embargo, las implementaciones de algoritmos de hash pueden solucionar esto .
Como ejemplo, bcrypt proporciona mecanismos para abordar el aumento de la velocidad de cálculo.
bcrypt usa el concepto de rondas para calcular hashes. Por ejemplo, bcrypt hash su contraseña con un salt y varias rondas:
bcrypt("password","salt",10000)
Nota: Como señalado por
darkhogg , el parámetro de rondas no se envía realmente a bcrypt. En su lugar se envía un factor de trabajo. La diferencia es que lo que se envía es en realidad un número N, que es el exponente utilizado para calcular las rondas. Entonces, aunque 10,000 se utilizan aquí como un ejemplo para el número de rondas, la unidad de trabajo real que necesitaría suministrar para obtener 10,000 rondas sería mucho más pequeña.
hash la sal y la contraseña combinadas 10.000 veces antes de almacenar el hash, la sal y el número de rondas. Entonces, supongamos que en el momento inicial de la implementación, 10,000 rondas de hashing toman .02 segundos. Un año después de la implementación inicial, se da cuenta de que 10,000 rondas solo toman .01 segundos, o la mitad del tiempo. Puedes cambiar las rondas a 20,000. La próxima vez que un usuario inicie sesión, su hash se computará con 10,000 rondas para autenticar, pero el hash se almacenará con 20,000 rondas, para una futura autenticación.