Es necesario que el hashing de contraseñas "ocupado" sea criptográficamente seguro

7

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:

  1. 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.

  2. 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.

  3. 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?

    
pregunta supercat 28.09.2014 - 21:17
fuente

2 respuestas

2
  

¿Es necesario que el "ocupado-trabajo" de hashing de contraseñas sea criptográficamente seguro

Sí. Necesita usar un algoritmo estándar para asegurarse de que no haya accesos directos disponibles para el "trabajo ocupado". Echa un vistazo a la la respuesta de Thomas Pornin aquí .

  

Insertar la sal (sí, se debe hablar de eso), e iterar la función al mismo tiempo, es un poco más complicado de lo que generalmente aparece. En particular, una función hash como SHA-256 no es exactamente una función de "oráculo aleatorio"; Exhibe alguna estructura interna. Cualquier construcción hecha en casa podría golpear uno de esos detalles finos de los cuales pueden surgir debilidades mortales.

     

Asegurarse de que lo hiciste bien es difícil, al igual que crear cualquier algoritmo criptográfico. Ahí es donde bcrypt es mejor que cualquier construcción casera: bcrypt se ha publicado y está en uso y, presumiblemente, ha sido inspeccionado por muchas personas durante bastante tiempo. Esta es básicamente la única medida de seguridad que puede obtener en la criptografía. El consejo genérico de "no defina sus propios algoritmos" se aplica aquí también.

En su declaración:

  

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 efectivamente, ¿habría alguna forma en que una función de trabajo ocupado deficiente pueda comprometer la seguridad, aparte de tomar ¿Tiempo lejos de las mejores funciones de trabajo ocupado?

Quitar el tiempo es bueno, aunque si existen accesos directos, el tiempo empleado sería mejor gastado en un método "probado y probado" de iterar el algoritmo de hash. Si el método probado y eficaz agregará efectivamente 10 bits de entropía con 1024 iteraciones, no desea que su función de "trabajo ocupado deficiente" pueda ser acceso directo, por lo que no se agrega una entropía equivalente adicional. Esto agrega tiempo para su sistema, pero ninguno para un atacante. Una buena función hash iterada debería agregar más tiempo para el atacante, ya que necesitará más conjeturas que un usuario válido.

Me doy cuenta de que su pregunta está en la línea de "asuma que el atacante tiene la forma más rápida de generar un hash", sin embargo, en mi hardware de producción quiero que se use "el método más rápido de crear un hash seguro" para cada plataforma . En ese caso, podría tener diferentes algoritmos para diferentes máquinas, pero debería usar los estándar (bcrypt, scrypt, PBKDF2) y estará a la merced del más débil si un atacante consiguió su base de datos de contraseñas.

En tu comentario a una respuesta anterior:

  

En la mayoría de las funciones criptográficas, la suposición es que el atacante no tendrá los parámetros necesarios para usar la función criptográfica en la dirección de avance y, por lo tanto, tendrá que revertirla y el objetivo es maximizar la diferencia de velocidad entre la marcha atrás. y direcciones hacia adelante. Agregar cosas inseguras reducirá la velocidad hacia adelante, pero probablemente no afectará tanto a la dirección inversa.

Una función hash criptográfica debería ser prácticamente imposible de invertir. Un atacante que intente descifrar un hash, de hecho, calculará sus conjeturas utilizando el mismo algoritmo que ha utilizado, por lo que irá en la "dirección de avance" para ver si tienen una coincidencia. No debe asumir que su "trabajo ocupado" o su algoritmo de hash es secreto; suponga que el único secreto que el atacante no conoce es la contraseña. La única vez que las cosas están en "dirección inversa" es cuando tienen una tabla hash o arco iris precalculada: si tienes una sal lo suficientemente fuerte, esto detendrá este vector de ataque.

Por lo tanto, parece que hay un error en su objetivo de hacer que una función hash sea rápida de ejecutar pero difícil de revertir. La ejecución debería ser lenta y imposible revertirse. El único "retroceso" que debe intentar frustrar es el de los intentos repetidos haciendo que el atacante haga más trabajo por conjetura.

    
respondido por el SilverlightFox 17.01.2015 - 19:17
fuente
1

En gran parte es una cuestión de semántica ... Crypto se trata de asegurarse de que el tiempo requerido para romperlo (suponiendo un cierto valor) sea lo más grande posible. "Quitar tiempo" significa que el atacante puede romper su seguridad más rápidamente. - Es decir, todo el cifrado en uso real puede "romperse" dado un tiempo infinito (por ejemplo: "simplemente" adivinar una clave privada).

Si su "pobre trabajo ocupado" es simplemente "agregue 10 al número X mil millones de veces", el atacante lo reducirá a "agregar 10 mil millones a X", eliminando toda la utilidad.

    
respondido por el Joel L 01.12.2014 - 16:11
fuente

Lea otras preguntas en las etiquetas