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

El aprueba el PBKDF2 al hashear 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í.

Consulte 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 compatible con FIPS.

PasswordDeriveBytes implementa la función de derivación de claves PBKDF1. Un KDF es una función que transforma una parte de datos secretos (aquí, una "contraseña", es decir, el tipo de datos que encaja en un cerebro humano y se puede escribir con dedos humanos) en una secuencia de bits adecuada para algoritmos que necesitan una clave simétrica (por ejemplo, cifrado simétrico). Un KDF no está destinado a nada más, 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 mayor que el tamaño de salida de la función hash. Sin embargo, tal KDF sería muy crudo. Una característica que debería proporcionar un buen KDF es ser adecuadamente lenta . Esto se debe a que las "contraseñas" son, por naturaleza, vulnerables a una búsqueda exhaustiva (también conocida como "ataque de diccionario": los usuarios tienden a elegir como contraseñas palabras o combinaciones más bien simples que pueden adivinarse 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 intenta autenticarse no verá la diferencia entre un retraso de 1µs y 1ms para la función de derivación de clave; pero una ralentizació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 diseñado exactamente para eso: hacer que la derivación de la clave sea lo suficientemente lenta, de 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, PBKDF1 no se recomienda; Se supone que PBKDF2, del mismo estándar , es más sólido.

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 un MAC (llamada es una "firma" impropia, pero extendida). Sin embargo, esto conlleva algún secreto en algún momento, una clave y una función de hash no tienen claves.

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

Para lo que está destinado, es crear una clave de cifrado, para el cifrado simétrico, basado en una contraseña proporcionada por el usuario.

Para aclarar, considere la siguiente situación:
Tienes una aplicación, que requiere encriptar un archivo. Esto se hace a discreción del usuario, y puede ser descifrado a su elección.
Oh, digamos que MS Word tiene una característica para cifrar su contenido. O un archivo ZIP encriptado.
Quiere darle al usuario el control para acceder a él, pero no quiere que el usuario genere una clave fuerte, aleatoria, de exactamente 256 bits, lo que dificultaría la memoria, etc.
Por lo tanto, permite que el usuario establezca la contraseña que desee, y derive la clave de cifrado a partir de eso.

En ningún momento está almacenando la contraseña, o utilizando un hash simple para almacenarla. Sólo está destinado a la creación de material clave.

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

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

Para versiones anteriores de Java, como se explica en BlackBerry App Security - Stack Overflow , una implementación de PBKDF2 se encuentra en Una implementación Java gratuita de RFC 2898 / PKCS # 5 PBKDF2

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

Utilizar 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 un salt, y si bien aún es posible que el desarrollador haga algo estúpido como codificar el salt, es al menos un paso más cerca que donde los desarrolladores normalmente cometen errores que no son sal y todo. El solo hecho de tener un salt hace que sea menos probable que ya haya una tabla arco iris por ahí. Esto va a funcionar con la contraseña trivial de alguien, y si se agrega al azar para cada usuario, se detiene la fuga de información cuando varios usuarios tienen la misma contraseña y hacen que esas contraseñas fáciles sean muy difíciles obtén porque tendrías que generar una tabla para cada sal.

2º, mientras que los RFC2898DeriveBytes desafortunadamente no te permiten elegir la función hash y utiliza HMAC-SHA1 y no es realmente un problema, ya que lo bueno de PBKDF1 es que el tamaño de tu llave puede ser tan grande como puedas querer. Así que eso ayuda a dificultar el almacenamiento y la difusión de tablas de arco iris frente a cualquier algoritmo hash estándar.

Finalmente, los conteos de iteraciones son clave! La cantidad de hash es muy lenta, el algoritmo hash estándar está diseñado para ser rápido, el almacenamiento de datos está creciendo exponencialmente, no se puede contar solo con el tamaño de su clave.

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

Cuando se encripta el cifrado, las cosas más importantes que se requieren para garantizar la seguridad son la longitud y una sal que es dinámica y no transparente para el usuario (es decir, el explotador no puede determinar qué es la sal). Si utiliza un almacén encriptado AES con una contraseña de 20 caracteres como mínimo, un salt aleatorio y 4K + iteraciones de SHA-256 (PBKDF2 recomienda al menos 1K iteraciones de SHA1 para sus propósitos), un hacker tendrá un momento muy difícil esa contraseña (ver: orden de magnitud en años o décadas si no más).

El cifrado de contraseñas 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.