Longitud de hash para almacenar la contraseña

Una mayor longitud de salida lo hace más fuerte, hasta un cierto punto que ya se ha alcanzado, por un amplio margen, cuando tiene una salida de 128 bits. Ampliarlo más no cambia la seguridad.

Detalles: salvo cualquier debilidad estructural, la seguridad de una función hash depende de su resistencia a los ataques genéricos (también conocida como "suerte": el atacante intenta entradas aleatorias hasta que se encuentra una coincidencia), y esa resistencia Depende del tamaño de salida del hash. Para una función hash con una salida de n bits, se requiere un esfuerzo 2ⁿ para que el atacante encuentre una imagen previa (es decir, alguna contraseña, no necesariamente el "real", que coincide con la salida). Los esfuerzos que van más allá de 2⁸⁰ están demasiado lejos de lo técnicamente inviable como para que un atacante pueda imaginarlo. Con 128 bits, ya tiene un margen de 2⁴⁸ , es decir, un factor de casi 300 miles de millones sobre lo que ya era demasiado caro. Sería como hacer alarde de reembolsar la deuda nacional de EE. UU. Sin tener más de $ 0.01 en efectivo.

El tamaño de salida más grande también ayuda contra las colisiones; de nuevo, los ataques genéricos basados en la suerte han costado a 2^n/2 (y ahí se ve por qué SHA-1 tiene una salida de 160 bits: para hacer el costo de la colisión de 2⁸⁰ inalcanzable). Sin embargo, las colisiones no son un problema para el hashing de contraseñas. La capacidad de calcular colisiones no le da ninguna ventaja al atacante. Sucede que las colisiones son también inviables con las funciones hash habituales, pero si fueran factibles, no sería un problema.

La verdadera debilidad en el hashing de contraseñas no es el hashing ; es la contraseña . O, más exactamente, la mente humana detrás de la contraseña. Los ataques exitosos en la contraseña con hash son ataques que intentan contraseñas potenciales, no ataques que funcionan en las debilidades estructurales de la función hash, en su caso. Las mitigaciones incluyen hashing lento y salado, que es lo que hace PBKDF2.

Puede almacenar solo 80 bits aproximadamente de salida PBKDF2 (y la sal); Las cosas seguirán siendo seguras. (Por razones puramente estéticas, haz que sean 128 bits: estos informáticos, les encantan los poderes de dos).

Sí, un hash de 512 bits es una exageración. 128 bits es suficiente.

Tenga en cuenta que la seguridad de su sistema es tan fuerte como el eslabón más débil. El enlace más débil, en este caso, es casi con seguridad la entropía de la contraseña del usuario. La mayoría de los usuarios eligen contraseñas deficientes que son fácilmente adivinable . Aumentar la longitud del hash no hace nada para detener este ataque.

Por esta razón, lo más importante es usar un esquema de hashing de contraseña diseñado para ralentizar los ataques de adivinación de las contraseñas de los usuarios, como bcrypt , PBKDF2 , o scrypt. Elija una serie de iteraciones que hacen que el hashing de contraseñas sea tan lento como pueda tolerar . Asegúrate de usar una sal al azar, también. Asegúrese de usar SSL para proteger la transmisión de las contraseñas del usuario a su sitio ; Le recomiendo que utilice SSL en todo el sitio . En otros lugares he ofrecido otras sugerencias sobre cómo mejorar la seguridad de la autenticación basada en contraseña .

Hay mucha información adicional en este sitio acerca de cómo proteger el almacenamiento de contraseñas. Pruebe la barra de búsqueda: debería encontrar todo tipo de buenos consejos y consejos útiles.

Si bien la seguridad de cualquiera de los dos esquemas de hash es funcionalmente equivalente a sus más de 100 bits a menos que exista algún defecto importante, no diría que un hash de 512 bits es excesivo . La longitud de un hash, siempre y cuando sus más de 128 bits sea irrelevante en gran medida.

¿Tiene suficientes contraseñas en su base de datos para almacenar un extra (512 bits = 64 bytes; 128 bits = 16 bytes) 48 bytes por usuario es significativo?

Demonios, muchos sistemas almacenarán tus hashes como cadenas hexadecimales ASCII (lo que significa que cada byte toma dos caracteres ASCII entre 0-9a-f para almacenar), que a menudo puedes optimizar el tamaño de tus hashes al ir a un blob binario si tu quieres. Sin embargo, rara vez le importa guardar docenas de bytes en un sistema moderno. Si tiene un millón de usuarios, todavía son solo 48 MB adicionales, lo que todavía es trivial para lanzar hardware. Y recomendamos el uso de hashes lentos (por ejemplo, bcrypt / scrypt), los problemas de rendimiento de búsqueda / comparación del hash son irrelevantes (de hecho, los hashes más grandes son ligeramente mejores en este aspecto, ya que serán un poco más lentos).

Yo uso SHA-512 crypt en mis sistemas linux. (Este no es un simple hash sha-512, sino que se compone de 5000 rondas (predeterminadas) de SHA- 512 .) No uso esto porque necesito más que la cripta SHA-256, pero fue la configuración predeterminada con mi distro (y los 43 bytes adicionales por usuario son completamente irrelevantes (está en una codificación similar a base64 )). Tiene un pequeño beneficio adicional si alguna vez se encuentra un ataque futuro en SHA que reduzca significativamente su complejidad, comencé desde una ubicación de inicio mucho más segura. (Por ejemplo, si encuentra un ataque de pre-imagen que lo simplifica por un factor de 2 ⁶⁴ , los hashes de 128 bits se ven comprometidos, mientras que los hashes de 256/512 bits estarían bien).