Todos los esquemas de hashing de contraseñas modernos están diseñados deliberadamente para incluir una gran cantidad de "trabajo ocupado", para limitar la velocidad con la que un atacante podría realizar intentos de hashing de contraseñas. Además, un objetivo en los esquemas más nuevos es reducir la cantidad en que el hardware de propósito especial puede hacerse más eficiente que el hardware de productos básicos de costo similar. Si una "unidad de trabajo" en cada uno de varios algoritmos se define como la cantidad de trabajo que se podría realizar por segundo por dólar de hardware que se optimizó para esa tarea, el objetivo es maximizar la cantidad de unidades de trabajo que se pueden realizar. en un marco de tiempo aceptable utilizando hardware de producción. Sin embargo, debido a que las máquinas de productos básicos difieren en la eficiencia con la que pueden realizar varias operaciones, esto sugeriría que diferentes algoritmos serían óptimos en diferentes máquinas de producción. Por ejemplo, aunque es deseable que los algoritmos sean GPU-hostiles si las máquinas de producción no tienen GPU, en las plataformas de producción que pueden usar una GPU, sería mejor tener un algoritmo de trabajo fácil para GPU.
Dado el algoritmo de hashing de contraseña:
hash = secureHash(password, salt)
Using one or more forms of busywork:
busyResult = busyWork(hash, params)
hash = secureHash(hash, busyResult, extraSalt)
Si se supone que secureHash tiene todas las propiedades necesarias para un hash seguro, ¿la seguridad general dependería de las propiedades criptográficas de las funciones busyWork utilizadas más allá del hecho de que sus resultados no sean computables sin realizar una cierta cantidad de trabajo? Si no, sería razonable favorecer diferentes tipos de trabajo ocupado en diferentes entornos de producción, si:
-
Cada registro de contraseña incluía una lista de las formas de trabajo ocupado que se utilizaron para crearla, junto con los parámetros apropiados.
-
Cada entorno de producción sería capaz de realizar todas las formas de trabajo ocupado, incluso si no es de manera óptima y eficiente.
-
En el caso de cambios de hardware que causen que el algoritmo de contraseña actual tome más tiempo del ideal, el hash de contraseña almacenado del usuario podría actualizarse de manera transparente para usar el nuevo algoritmo en el próximo inicio de sesión del usuario (el usuario no debe saber esto estaba ocurriendo).
Tratar de diseñar un algoritmo de hashing seguro para cada sabor diferente del sistema que fue optimizado alrededor de las habilidades precisas de ese sistema sería difícil. Sin embargo, si el requisito fuera más débil, y solo era necesario mostrar que el algoritmo de trabajo ocupado estaba cerca de los medios más rápidos para producir cierta salida en un sistema dado, y que sería probable que cada valor hash diferente introducido en el algoritmo producir salidas diferentes (no es difícil hacer si la salida podría ser mucho más grande que la entrada), parece que producir algoritmos optimizados para diferentes plataformas sería mucho más fácil.
Pregunta principal: Si la función secureHash es buena, y el tiempo requerido para al menos algunas de las funciones de trabajo ocupado no se puede reducir de manera efectiva, ¿habría alguna forma en que un la mala función de trabajo ocupado podría comprometer la seguridad, aparte de quitarle tiempo a las mejores funciones de trabajo ocupado?