BCrypt + SHA256 vs PBKDF2-SHA256

4

De esta pregunta , el OP propuso tomar la contraseña ingresada por un usuario, ejecutarla a través de BCrypt y luego ejecutar that a través de SHA256 para generar una clave derivada de contraseña de 256 bits. ( EDITAR: para aclarar, estas dos opciones se consideran que producen un solo valor de clave; el único propósito del hash de BCrypt "intermedio" es el hash con SHA-256 y no se usa para ningún otro propósito) . La alternativa obvia es simplemente conectar HMAC-SHA256 como el PRNG para el shell del algoritmo PBKDF2, con un número equivalente de rondas de derivación.

La pregunta es, ¿cuáles son las fortalezas y debilidades relativas aquí? Obviamente, ambos enfoques, correctamente implementados y configurados, presentarían una prueba significativa del trabajo a un atacante. La combinación BCrypt + SHA256 parece un poco más compleja, pero si tiene implementaciones ya hechas de estos dos y tendría que rodar su propia implementación PBKDF2 (el PBKDF2 integrado en .NET está codificado para usar SHA1, no SHA256), la primera La opción terminaría más sencilla. Veo una ventaja para PBKDF2 cuando se implementa con un HMAC de 256 bits; El hash de BCrypt real es solo de 192 bits, de modo que, y no de 256 bits, es la cantidad máxima de entropía inherente en el combo BCrypt + SHA256 en lugar de un máximo verdadero de 256 bits con PBKDF2-SHA256. BCrypt + SHA256 aún sería mejor que la implementación de BKDF2 de 160 bits de Rfc2898DeriveBytes en .NET, e incluso de 128 bits, producida al truncar o plegar XOR cualquiera de los hashes anteriores, es lo suficientemente segura con un buen modo AES AEAD. / p>

Opiniones?

    
pregunta KeithS 23.01.2013 - 05:35
fuente

2 respuestas

2

El hash del resumen de BCrypt con SHA-256 expondrá de forma trivial las claves de cifrado si su base de datos de contraseñas está comprometida. El uso del PBKDF2 de la propia contraseña para las claves de cifrado evita esto.

Por supuesto, hay inconvenientes. Con el esquema descrito, el servidor puede realizar operaciones criptográficas con la clave del usuario en cualquier momento, lo que puede ser conveniente o necesario. Cuando se utiliza el PBKDF2 de la contraseña del usuario, el servidor no puede volver a generar esta clave sin que el usuario proporcione su contraseña.

    
respondido por el Stephen Touset 23.01.2013 - 10:18
fuente
0

Bcrypt ya conserva la sal, por lo que parece que el problema que estamos tratando de resolver aquí es la entropía limitada del compendio estándar de 184 bits y los 256 en la pregunta.

Argumentaría que cambiar la implementación para obtener algunos bits adicionales de entropía es un riesgo que supera con creces la ganancia potencial:

La recompensa se sobrestima como el poder de cómputo involucrado en el forzamiento bruto de un hash bcrypt de 184 bits con un factor de trabajo sustancial ( 1 segundo o más ) es fundamentalmente prohibitivo, incluso con buenas listas de palabras. Claro que 256 bits también es fundamentalmente prohibitivo, pero es el final de los órdenes de magnitud donde no se obtiene ninguna protección adicional y, dado los riesgos, no vale la pena.

Lo mejor es seguir con la implementación de stock bcrypt y elegir un factor de trabajo más grande, el factor de trabajo más grande que el UX de su sistema puede tolerar. Esto asegurará el riesgo más bajo con la planificación a futuro y evitará errores con la forma en que se trocean sus contraseñas.

    
respondido por el cottsak 08.03.2017 - 03:13
fuente

Lea otras preguntas en las etiquetas