Para credenciales de alta entropía, ¿es suficiente el hashing SHA256?

3

Digamos que tengo una base de datos de credenciales de alta entropía (por ejemplo, valores aleatorios de 256 bits) que los clientes utilizan como claves API. Me gustaría incluirlos en mi base de datos para que un compromiso con la base de datos no permita que un atacante acceda a mi API con credenciales robadas.

Ahora, dado que he garantizado valores de alta entropía (no son cortas o fáciles de adivinar "contraseñas"), ¿existe realmente una ventaja en algo como bcrypt? ¿Podría hacerlo efectivamente igual de bien con, digamos, SHA256 sin sal?

    
pregunta Bosh 05.05.2016 - 05:46
fuente

2 respuestas

3

Quiero hacer algunos puntos además de la excelente respuesta de @ NeilSmithline.

Si toma un valor aleatorio de 256 bits y lo mezcla con SHA-256, la salida seguirá teniendo (aproximadamente) 256 bits de entropía. Digo "aproximadamente" porque es un problema abierto si SHA256 en realidad se asigna a cada cadena posible en 256 bits, pero para todos los propósitos prácticos, es lo suficientemente cerca.

Bcrypt: la ventaja de bcrypt es que requiere que el atacante haga muchas rondas de hash en cada suposición, lo que reduce su velocidad y aumenta sus costos de electricidad.

Fuerza bruta: Digamos que algún tonto quería probar la fuerza bruta de sus cadenas aleatorias de 256 bits SHA256. En promedio, tendrían que hacer 2 255 conjeturas. Suponiendo que cada suposición tomó 1 nanosegundo y consumió la energía de un electrón, tomaría 10 60 años (que es 10 50 * ageOfUniverse) y requeriría un motor que consuma la energía equivalente a 9,000 galaxias de la Vía Láctea . 2 256 es un número grande.

Línea inferior: así que, sí, nadie irá a forzar tus valores aleatorios de 256 bits que has ejecutado a través del SHA256 sin sal, no hay razón para agregar cálculos adicionales en forma de bcrypt. Le agradezco que piense en la seguridad y haga buenas preguntas :-)

(En realidad, el enlace débil es su generador de números aleatorios, no el hashing. Si un atacante puede reducir la lista de posibles semillas para el RNG que generó esos valores aleatorios, entonces podría ser posible un ataque de diccionario. el caso bcrypt podría agregar alguna desaceleración útil.)

    
respondido por el Mike Ounsworth 05.05.2016 - 07:56
fuente
4

Sí. Salt se usa para prevenir ataques de precomputación, pero las cadenas aleatorias de 256 bits son demasiado grandes para la precomputación. Las funciones hash lentas con muchas iteraciones están destinadas a ralentizar los ataques de diccionario, pero las cadenas aleatorias de 256 bits son demasiado grandes para un diccionario o para pruebas exhaustivas. Por lo tanto, un solo hash SHA256 es seguro para entradas aleatorias largas y criptográficamente seguras.

    
respondido por el Neil Smithline 05.05.2016 - 06:31
fuente

Lea otras preguntas en las etiquetas