it-swarm-es.com

¿Es System.Cryptology.RFC2898DeriveBytes () basado en PBKDF2 "mejor" para el hash de contraseña Unicode que los métodos tradicionales?

¿Cuándo es apropiado usar RFC2898DeriveBytes versus un hash típico?

Actualización

Ahora entiendo que un KDF se usa generalmente para crear una clave simétrica para su posible uso en el cifrado de una secuencia. Ahora también entiendo que PBKDF2 obsoletos PasswordDeriveBytes . La intención de esta pregunta es explorar la posibilidad de volver a utilizar el KDF como una forma sólida de almacenar una contraseña hash. El contenido que pretendo cifrar es una cadena Unicode que un humano puede recordar y escribir en una computadora.

La razón por la que estoy interesado en el KDF es porque es

  1. Lento y, por lo tanto, computacionalmente costoso para crear una tabla Rainbow
  2. La biblioteca base en .NET es FIPS aprobado y es posible usar este KDF con recomendaciones NIST si usamos SHA-256

Pregunta

¿Cuáles son los argumentos a favor/en contra de usar un KDF de esta manera en oposición al método de hashing normal? (Descargo de responsabilidad: ¿Qué es el método de hash normal?)

15

El NIST aprueba PBKDF2 al cifrar y almacenar contraseñas, sin embargo, ese no es su propósito original. Notablemente, StackExchange también usa PBKDF2 para el mismo propósito. El código fuente está disponible aquí.

Ver esta respuesta para una comparación entre BCrypt y PBKDF2. BCrypt es el método más convencional para almacenar contraseñas.

Estoy considerando PBKDF2 ya que está integrado en .NET y ya es FIPS compatible.

14
goodguys_activate

PasswordDeriveBytes implementa la función de derivación de clave PBKDF1. Un KDF es una función que transforma un dato secreto (aquí, una "contraseña", es decir, el tipo de datos que cabe en un cerebro humano y puede escribirse con dedos humanos) en una secuencia de bits adecuada para algoritmos que necesitan un clave simétrica (por ejemplo, cifrado simétrico). Un KDF no está destinado a otra cosa, en particular al almacenamiento de contraseñas.

Se puede usar una función hash como KDF, siempre que la clave simétrica que necesita no sea más larga que el tamaño de salida de la función hash. Sin embargo, tal KDF sería muy crudo. Una característica que debe proporcionar un buen KDF es ser adecuadamente lenta . Esto se debe a que las "contraseñas" son, por naturaleza, vulnerables a la búsqueda exhaustiva (también conocido como "ataque de diccionario": los usuarios tienden a elegir como contraseñas palabras o combinaciones simples que se pueden adivinar con solo unos pocos millones o miles de millones de intentos). En un sistema dado, generalmente se puede tolerar un KDF relativamente lento: un usuario que intente autenticarse no verá la diferencia entre un retraso de 1 µs y 1 ms para la función de derivación de clave; pero una desaceleración de 1000x es mortal para el atacante: convierte un esfuerzo de ruptura de un día en un esfuerzo de ruptura de tres años .

PBKDF1 incluye un "recuento de iteraciones", que es un parámetro destinado exactamente a eso: hacer que la derivación de clave sea lo suficientemente lenta, de una manera configurable. Una simple función hash es demasiado rápida para eso. El uso como KDF es precisamente donde preferiría PBKDF1 sobre una función hash. En realidad, no se recomienda PBKDF1; Se supone que PBKDF2, del mismo estándar , es más robusto.

Las funciones hash son objetos mucho más genéricos que KDF, y tienen muchos otros usos, que KDF no cumple.

Lo que quiere hacer no está claro: utiliza el término "firma", que normalmente significa "firma digital asimétrica" ​​como con RSA o ECDSA; hay algunas personas que tienden a usar el término "firma" para designar una verificación de integridad simétrica, como MAC (llamarlo "firma" es incorrecto , pero generalizado). Sin embargo, esto implica algún secreto en algún momento, una clave y una función hash no tiene clave.

16
Thomas Pornin

A menos que me haya perdido algo, PasswordDeriveBytes, y otras implementaciones de PBKDF, no están destinadas a almacenar contraseñas, ni deben usarse en lugar de un hash "típico".

Lo que se pretende es crear una clave de cifrado, para cifrado simétrico, basada en una contraseña proporcionada por el usuario.

Para aclarar, considere la siguiente situación:
Tiene una aplicación que requiere cifrar un archivo. Esto se hace a discreción del usuario y se puede descifrar a su elección.
Oh, digamos que MS Word tiene una función para cifrar su contenido. O un archivo Zip encriptado.
Desea darle al usuario el control para acceder a él, pero no quiere confiar en que el usuario genere una clave fuerte, aleatoria, exactamente de 256 bits, lo que dificultaría su recuerdo, etc.
Entonces, le permite al usuario establecer cualquier contraseña que quiera - y derivar la clave de cifrado de eso.

En ningún momento está almacenando la contraseña o está utilizando un hash simple para almacenarla. Solo está destinado a crear material clave.

6
AviD

PBKDF2 es mejor que PBKDF1, que fue obsoleto en RFC 2898 hace 10 años. Se implementa para .NET en Rfc2898DeriveBytes Class (System.Security.Cryptography)

Me alegra ver también que a partir de Java 6 hay una implementación de PBKDF2: PBKDF2WithHmacSHA1 en SunJCE.

Para versiones anteriores de Java, como se discutió en BlackBerry App Security - Stack Overflow , una implementación de PBKDF2 está en A gratis Java implementación de RFC 2898/PKCS # 5 PBKDF2

Sin embargo, me pregunto si usar SHA-256 sería mejor que SHA-1, que ahora está en desuso.

4
nealmcb

Usar RFC2898DeriveBytes con un recuento de iteración no trivial debería ser mejor que usar una función hash directa para fines de autenticación.

Primero requiere que pongas sal, y aunque todavía es posible que el desarrollador haga algo estúpido como codificar la sal, está al menos un paso más cerca de donde los desarrolladores normalmente se equivocan, lo que no es sal y todo. Solo tener una sal hace que sea menos probable que una tabla Rainbow ya funcione funcionará con la contraseña trivial de alguien y si se usa aleatoriamente para cada usuario, se detiene la filtración de información cuando varios usuarios tienen la misma contraseña y hace que esas contraseñas fáciles sean muy difíciles de usar. obtener porque tendrías que generar una tabla para cada sal.

Segundo, mientras que RFC2898DeriveBytes desafortunadamente no le permite elegir la función hash y usa HMAC-SHA1 y no es realmente un problema, ya que lo bueno de esto frente a PBKDF1 es que el tamaño de su clave puede ser tan grande como prácticamente podría desear. Eso ayuda a dificultar el almacenamiento y la difusión de las tablas Rainbow frente a cualquier algoritmo hash estándar.

Finalmente, ¡los recuentos de iteraciones son clave! Tenga un conteo realmente lento lento que disminuya el cálculo de hash, los algoritmos de hash estándar están diseñados para ser rápidos, el almacenamiento de datos está creciendo exponencialmente, no puede contar con solo el tamaño de su clave.

3
jbtule

La pregunta del OP y el objetivo de dicha pregunta son algo contradictorios. Como todo el mundo está señalando, PBKDF2 no se utiliza principalmente para el cifrado/almacenamiento de contraseñas, sino para la generación de claves. Más comúnmente, se usa en WPA2 PMK y otros esquemas de generación de claves WPA, usando componentes de ejemplo como la contraseña + una sal del nombre SSID y la longitud del nombre SSID, que luego se ejecuta a través de un 4096 iteración hash SHA1.

Al encriptar pases, lo más importante que se requiere por razones de seguridad es la longitud y una sal que sea dinámica y no transparente para el usuario (es decir: el explotador no puede determinar cuál es la sal). Si usa una tienda cifrada AES con una contraseña mínima de 20 caracteres, una sal aleatoria e iteraciones 4K + de SHA-256 (PBKDF2 recomienda al menos 1K iteraciones de SHA1 para sus propósitos), un hacker tendrá dificultades para romper esa contraseña (ver: orden de magnitud en años o décadas, si no más).

El cifrado de contraseña también depende en gran medida del uso final (velocidad, necesidad de nivel de seguridad, etc.), por lo que sin saber qué uso final potencial es más difícil recomendar una solución ideal.

1
mrnap