¿Cómo puede bcrypt tener sales incorporadas?

Question

¿Cómo puede bcrypt tener sales incorporadas?

El artículo de Coda Hale "Cómo Almacenar de forma segura una Contraseña" afirma que:

Bcrypt tiene sales incorporadas para prevenir ataques de tablas rainbow.

Cita este documento , que dice que en la implementación de OpenBSD de bcrypt:

OpenBSD genera la sal bcrypt de 128 bits a partir de un arcfour (arc4random (3)) flujo de claves, sembrado con datos aleatorios el núcleo recoge los tiempos del dispositivo.

No entiendo cómo puede funcionar esto. En mi concepción de una sal:

Debe ser diferente para cada contraseña almacenada, de modo que se tendría que generar una tabla rainbow separada para cada
Debe almacenarse en algún lugar para que sea repetible: cuando un usuario intenta iniciar sesión, tomamos su intento de contraseña, repetimos el mismo procedimiento de salt-and-hash que hicimos cuando almacenamos originalmente su contraseña, y comparamos

Cuando estoy usando Devise (un gestor de inicio de sesión de Rails) con bcrypt, no hay ninguna columna de salt en la base de datos, así que estoy confundido. Si la sal es aleatoria y no se almacena en ningún lugar, ¿cómo podemos repetir de forma fiable el proceso de hash?

En resumen, ¿cómo puede bcrypt tener sales incorporadas?

475

security hash internals bcrypt

Author: Nathan Long, 2011-07-26

Source

2 answers

Creo que esa frase debería haber sido redactada de la siguiente manera:

Bcrypt tiene sales integrado en los hashes generados para evitar ataques de mesa arco iris.

La utilidad bcrypt no parece mantener una lista de sales. Más bien, las sales se generan aleatoriamente y se agregan a la salida de la función para que se recuerden más tarde (de acuerdo con la implementación de Java de bcrypt). Dicho de otra manera, el "hash" generado por bcrypt no es sólo el hash. Más bien, es el hachís y la sal concatenada.

140

Author: Adam Paynter,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-07-26 15:34:14

score 612 · Accepted Answer

Esto es bcrypt:

Genera una sal aleatoria. Se ha preconfigurado un factor de "costo". Obtén una contraseña.

Derive una clave de cifrado de la contraseña usando el factor salt y costo. Utilícelo para cifrar una cadena bien conocida. Almacenar el costo, sal, y texto cifrado. Debido a que estos tres elementos tienen una longitud conocida, es fácil concatenarlos y almacenarlos en un solo campo, sin embargo, ser capaz de separarlos más tarde.

Cuando alguien intenta autenticar, recuperar el costo almacenado y la sal. Derive una clave de la contraseña de entrada, el costo y la sal. Cifrar la misma cadena conocida. Si el texto cifrado generado coincide con el texto cifrado almacenado, la contraseña es una coincidencia.

Bcrypt opera de una manera muy similar a los esquemas más tradicionales basados en algoritmos como PBKDF2. La principal diferencia es su uso de una clave derivada para cifrar texto plano conocido; otros esquemas (razonablemente) asumen que la función de derivación de clave es irreversible, y almacene la clave derivada directamente.

Almacenado en la base de datos, un bcrypt "hash" podría verse algo como esto:

2 2a vI 10 vI vI8aWBnW3fID., ZQ4/zo1G.q1lRps.9cGLcZEiGDMVr5yUP1KUOYTa

Estos son en realidad tres campos, delimitados por " { " :

2a identifica la versión del algoritmo bcrypt que se utilizó.
10 es el factor de coste; 2¹⁰ iteraciones de la función de derivación de clave se utilizan (que no es suficiente, por cierto. Yo recomendar un costo de 12 o más.)
vI8aWBnW3fID.ZQ4/zo1G.q1lRps.9cGLcZEiGDMVr5yUP1KUOYTa es la sal y el texto cifrado, concatenado y codificado en una Base-64 modificada. Los primeros 22 caracteres decodifican a un valor de 16 bytes para la sal. Los caracteres restantes son texto cifrado que se comparará para la autenticación.

Este ejemplo está tomado de la documentación para la implementación de ruby de Coda Hale.