Gold Standard para el hashing de contraseñas

10

He desarrollado una aplicación web que tratará con información altamente confidencial y quiero asegurar que el hashing de las contraseñas sea el estándar de oro. Lo ideal sería optar por SHA512 salado por usuario utilizando PBKDF2 para realizar múltiples iteraciones del algoritmo, pero como estoy desarrollando en asp.net, no hay una versión incorporada de .net SHA512 para PBKDF2. Estoy limitado a SHA1 (es decir, Rfc2898DeriveBytes).

Mi pregunta es realmente, teniendo en cuenta que estoy desarrollando en .net y asegurando información confidencial, ¿cuál es la mejor manera de hashear las contraseñas de los usuarios?

¿Debo seguir con la implementación SHA1 PBKDF2 de .net?
¿Debo usar una implementación personalizada de PBKDF2 para incorporar SHA512?
¿Debería preferir bcrypt o scrypt a pesar de que no están ampliamente acreditados por los estándares (por ejemplo, NIST)?

    
pregunta Drunk Goldfish 12.12.2012 - 14:47
fuente

5 respuestas

9

Iría por Rfc2898DeriveBytes incorporado, con un alto número de iteraciones: cuanto mayor sea el número, mejor, pero recomendaría 5000 como mínimo absoluto. SHA1 se considera roto para algunos usos, pero no en la forma en que se usa en PBKDF2, y probablemente nunca estará dentro de la vida útil de su producto.

Sin embargo, implementar tu propio PBKDF2 con SHA512 no debería ser difícil. De hecho, Microsoft proporciona una implementación de referencia que usa SHA256.

    
respondido por el Polynomial 12.12.2012 - 14:57
fuente
10

Bcrypt es marginalmente "mejor "que PBKDF2 . Sin embargo, PBKDF2 ya está bastante bien: si se usa correctamente, deja de ser el punto más débil de su sistema.

Recuerde que el punto de las iteraciones en PBKDF2 es hacer que el hash de contraseña sea lento para el atacante. Desafortunadamente, también lo hace lento para ti. Por lo tanto, debe evitar que sea excesivamente lento para usted. En particular, considere SHA-512: SHA-512 usa muchas operaciones aritméticas de 64 bits. El atacante puede comprar una PC que sea buena para operaciones de 64 bits (la CPU x86 suficientemente reciente tiene un modo de 64 bits, y los procesadores más antiguos podrían usar códigos de operación SSE2). Su servidor, por otro lado, podría ser un poco más limitado: si su servidor se ejecuta en modo de 32 bits, entonces el SHA-512 será bastante lento para usted (porque usa .NET y en .NET no tiene problemas con Opcodes SSE2), que le da al atacante una ventaja informática (en un factor de aproximadamente 6).

El uso de la implementación PBKDF2 proporcionada por el sistema maximiza las posibilidades de que no tenga una ralentización artificial (en particular, podría usar una implementación de código nativo de SHA-1). Las deficiencias conocidas de SHA-1 no afectan su seguridad cuando se utilizan en PBKDF2.

Si haces algo "por ti mismo", debes comprender estos problemas de rendimiento con todos sus detalles finos; y, si algo sale mal, probablemente tendrás la culpa.

    
respondido por el Thomas Pornin 28.12.2012 - 17:28
fuente
6

Personalmente, seguiría adelante y usaría BCrypt. Es posible que el algoritmo no esté incluido en la lista del NIST, pero ya lleva bastante tiempo (13 años, y el cifrado de Blowfish casi 20) en el que podría confiar. En comparación, se demostró que la MD5 era vulnerable solo 5 años después de su introducción y se consideró completamente rota en 18 años.

El único ataque conocido en el cifrado Blowfish en sus 20 años es un ataque de texto simple conocido, que requiere un número exponencial de mensajes de entrada conocidos y textos cifrados resultantes (2 ^ 8n + 1 donde n es el número de rondas del cifrado Feistel ; para Blowfish estándar de 16 rondas que es 2 ^ 129) para derivar la clave. Para BCrypt, este mismo ataque es inviable; En primer lugar, solo hay un texto sin formato que es "válido" para BCrypt (la cadena ASCII "OrpheanBeholderScryDoubt"), y segundo, la clave que se aplicaría mediante ingeniería inversa mediante la alimentación en otros campos de texto es el resultado de la función de derivación de clave compleja exponencialmente Eso confunde la contraseña en primer lugar. Hubo una vulnerabilidad mostrada en una implementación de C para los sistemas Unix, que rompió el algoritmo si se le proporcionó una contraseña que contenía caracteres ASCII no básicos; como resultado, los nuevos algoritmos que no tienen la vulnerabilidad deben ir precedidos de la variante BCrypt "$ 2y $" (aunque la mayoría aún usa el antiguo "$ 2a $", que es ambiguo; el algoritmo que generó el hash podría ser seguro, pero tal vez no).

Ahora, si bien prefiero BCrypt, PBKDF2 no se queda atrás. Aunque SHA-1 se considera vulnerable debido a su complejidad constante y relativamente baja, el costo estimado para romper un solo hash al alquilar suficiente CPU de un proveedor de la nube para ejecutar ese ataque sería de aproximadamente $ 2.77 millones. En PBKDF2, SHA-1 se usa como HMAC, lo que significa que el hashing SHA-1 se realiza al menos dos veces por iteración de la función de derivación. Con 5,000 iteraciones y una longitud de clave de 320 bits (que requieren dos conjuntos de 5,000 iteraciones, una para cada mitad de la clave derivada), cualquier vulnerabilidad en la ruptura de un solo hash se compensa con el hecho de que tendría que realizar una ingeniería inversa de veinte miles de ellos (añadiendo complejidad en el orden de 2 ^ 14.3, haciendo que el ataque completo sea algo así como 2 ^ 175).

Multiplicar el costo de $ 2.7 millones para romper un hash SHA por la complejidad incrementada le da ... un precio de alrededor de $ 55.4 billones para romper un hash PBKDF2 "a lo largo" (sin saber nada acerca de la contraseña de entrada). Cualquiera que tenga ese tipo de rasguño, y quiere su secreto, encontrará una forma más económica .

    
respondido por el KeithS 12.12.2012 - 17:41
fuente
1

Si le preocupa la seguridad de la contraseña de alguien, debe alejarse de PBDKF2 y, al menos, a BCrypt. Observe el estado del arte en el cracking de hardware.

Para obtener información sobre el cracking de BCrypt en hardware, consulte Implementación de alta velocidad de la contraseña de bcrypt Busque utilizando hardware de propósito especial .

| Algorithm  | hashes/sec | hashes/sec/Watt |
|------------|------------|-----------------|
| BCrypt(12) |      410.4 |           20.52 |
| BCrypt(5)  |   51,437   |        2,572    |

Crean un ASIC personalizado (el "Virtex-7" ), que es 10 veces más rápido que una CPU (y 30 veces más rápido que una tarjeta de video), y utiliza el 6% de la potencia de cualquiera .

Este es el estado del arte de descifrar contraseñas de BCrypt. Ahora compara eso con PBKDF2 . Tengo una memoria USB de 2.5W que calcula 350 hashes por segundo . Puede probar 1,000 iteraciones, 5,000 iteraciones, e incluso iteraciones estándar de iOS 10,000:

| Algorithm   | hashes/sec | hashes/sec/Watt |
|-------------|------------|-----------------|
| BCrypt(12)  |      410.4 |           20.52 |
| BCrypt(5)   |   51,437   |        2,572    |
| PBKDF2(10k) |   35,000   |       14,000    |
| PBKDF2(5k)  |   70,000   |       28,000    |
| PBKDF2(1k)  |  350,000   |      140,000    |

Cada una de las memorias USB de 2.5W cuesta aproximadamente $ 8 (tengo 14 de ellas conectadas a mi servidor).

  • Virtex-7 ASIC personalizado: $ 3,495
  • dispositivo USB : $ 8

Usando los costos

| Algorithm   | hashes/sec | hashes/sec/Watt | hashes/sec/$ |
|-------------|------------|-----------------|--------------|
| BCrypt(12)  |      410.4 |           20.52 |       0.1174 |
| BCrypt(5)   |   51,437   |        2,572    |      14.717  |
| PBKDF2(10k) |   35,000   |       14,000    |   4,375      |
| PBKDF2(5k)  |   70,000   |       28,000    |   8,750      |
| PBKDF2(1k)  |  350,000   |      140,000    |  43,750      |
    
respondido por el Ian Boyd 16.05.2015 - 15:36
fuente
0

Por lo que sé, todas las funciones de derivación de claves mencionadas están bien para usar. Incluso podría usar BCrypt.net , porque es el algoritmo que decide sobre la debilidad / fortaleza de los valores hash y no el Implementación de la biblioteca. Siempre que la biblioteca calcule los valores correctos, debería estar bien.

    
respondido por el martinstoeckli 12.12.2012 - 15:04
fuente

Lea otras preguntas en las etiquetas