¿Cuáles son los pros y los contras de usar sha256 para codificar una contraseña antes de pasarla a bcrypt?

Question

¿Cuáles son los pros y los contras de usar sha256 para codificar una contraseña antes de pasarla a bcrypt?

#1 de Shane Andrie (2 votos)
#2 de Xenos (1 votos)
#3 de tenmiles (-2 votos)

12

Hace poco me di cuenta del hecho de que bcrypt trunca las contraseñas a 72 caracteres. En la práctica, mi intuición es que esto no plantea ningún problema de seguridad importante. Sin embargo, entiendo que significa que cualquier biblioteca de software que use bcrypt posiblemente sufra un "error" en el que dos contraseñas ultra largas que comiencen con los mismos 72 caracteres serán equivalentes.

Los autores del marco web de Django escribieron algo llamado BCryptSHA256PasswordHasher para resolver este problema; lo que hace es primero hash de las contraseñas de los usuarios con SHA256 antes de pasarlas a bcrypt.

Algunos desarrolladores de mi equipo estaban debatiendo los méritos de este enfoque y solo quería recopilar ideas de la comunidad en general. Por un lado, ¿no es esto, en cierto sentido, reducir la seguridad al reducir el espacio total de posibles valores que se introducen en bcrypt? SHA256 siempre generará 32 bytes, muy por debajo de los 72 (significativos) bytes que tendríamos de otro modo. Por otro lado, sin hash de contraseñas primero, esencialmente tenemos un espacio distribuido de manera desigual donde, por cada prefijo de 72 caracteres, todas las contraseñas que comienzan con ese prefijo chocan.

Mi intuición es que el problema de distribución de más de 72 bytes no es importante y que BCryptSHA256PasswordHasher realmente no es útil. Dicho esto, también reconozco que, en general, los marcos que son tan populares y ampliamente utilizados como Django tienden a tomarse estas cosas en serio y tienen buenas razones detrás de sus decisiones. Así que realmente no tengo mucha confianza en mi instinto, si eso tiene sentido.

¿Estoy equivocado? ¿Las contraseñas de hash con SHA256 antes de bcrypt no reducen la seguridad, incluso teóricamente? ¿Es el problema de distribución más grave de lo que me doy cuenta? ¿Hay algo más en lo que simplemente no estoy pensando?

passwords sha256 bcrypt python django

pregunta Dan Tao 22.06.2015 - 16:48

fuente

3 respuestas

Lea otras preguntas en las etiquetas passwords sha256 bcrypt python django

¿Por qué las CPU están diseñadas de manera que el exploit de "fusión" funciona? [duplicar] ¿Es peligroso mostrar todas las funciones de JavaScript en mi aplicación web? [duplicar]

score 2 · Answer 1

Bcrypt como se indica en el enlace está limitado a 72 caracteres.

SHA256 puede tener un tamaño de SALIDA de solo 32 bytes, su entrada de Mensaje es ((2 ^ 64) -1) \ 8 o aproximadamente

2305843009213693952 Bytes (suponiendo que un char es de 8 bits)

Para Bcrypt está recibiendo una frase de contraseña de 32 bytes para cifrar, Para SHA256 que podría ser un flujo de datos de 400 Char (contraseña de IE).

Entonces no, no estás perdiendo la entropía en esto, estás superando una limitación en el diseño de Bcrypts (si quieres llamarlo una limitación.

El enlace en SHA2 que discute son tamaños: enlace

score 1 · Answer 2

De acuerdo con documentación de Django es porque

la contraseña se trunca en el primer byte NULO (si existe) y solo se copian los primeros 72 bytes de una contraseña ... todo el resto se ignora.

Reconocen que no es un problema de seguridad:

Aunque no es un problema de seguridad por sí mismo, bcrypt tiene una limitación importante (ver anterior)

Además, señalan que el final de las contraseñas de 72C no es "tan importante como" el resto:

Además, los bytes 55-72 no están completamente mezclados con el hash resultante (¡cita requerida!).

Podría traducirlo por "el final de la contraseña es más fácil de descifrar que el principio".

Es por eso que hacen que a tiene primero (que no tiene carácter NULL, tiene menos de 72 caracteres y no tiene 55-72 caracteres):

Para solucionar estos dos problemas, muchas aplicaciones ejecutan primero la contraseña a través de un resumen de mensaje como SHA2-256. Passlib ofrece la versión previa de passlib.hash.bcrypt_sha256 - BCrypt + SHA256 para solucionar este problema.

Esto mejora la seguridad si tiene contraseñas largas para manejar. Esto puede disminuirlo ligeramente si solo tiene contraseñas habituales (A-Za-z0-9 y caracteres especiales del teclado) debido a posibles colisiones (no es tan importante). Así que para una biblioteca genérica, tiene sentido el hash. Para un sitio web / aplicación de lambda que administre la contraseña de usuario, parece inútil (tiene más riesgos al hacerlo mal que al no hacerlo).

score -2 · Answer 3

Creo que el uso de hash de la contraseña antes de enviarla a bcrypt es superar los malos hábitos de contraseña. Siempre y cuando estés generando contraseñas aleatorias, usar hash será un detrimento.

Digamos que tu contraseña es. Así que ahora puedo guardar mis 72 caracteres en un documento y copiarlos / pegarlos y luego agregar el nombre de la computadora en la que está (o algún otro cálculo que sea fácil de hacer para un ser humano). Como vemos, esto resultará esencialmente en que todos sean la misma contraseña. Al hacer un hash, podemos evitar esto, pero al costo del espacio de teclas porque el algoritmo en particular estamos utilizando las salidas de 32 caracteres.

Ahora, supongamos que cada vez que configura una contraseña se genera aleatoriamente, todo. Una contraseña de 72 caracteres tiene (95 ⁷²) combinaciones . Su probabilidad de colisión es 1/95 ⁷².

Si tenemos este valor aleatorio, obtendremos 1 de 95 valores ³² y, por lo tanto, nuestra probabilidad de colusión es 1/95 ³². Así que ya podemos ver que el hash nos cuesta algo de seguridad.

Aunque hay más que eso. Si consideramos que el hash siempre generará una cadena de 32 caracteres, incluso si la entrada tiene menos de 32 caracteres, entonces tenemos exactamente 95 contraseñas posibles ³². Pero bcrypt tomará las contraseñas en un rango de longitudes (31, 55, etc.). Así que también puedes contarlos (95 ⁷² +95 ⁷¹ +95 ⁷⁰ +95 ⁶⁹ ... ) que se acumulan rápidamente, lo que resulta en una mayor disparidad entre los dos métodos.

Eso es lo teórico, pero ¿qué pasa con lo práctico? ¿Cuántos caracteres necesitamos para una seguridad adecuada? Si nos llevara más tiempo que la muerte térmica del universo encontrar una colisión en un hash de 32 caracteres (no sé que sea un hecho, solo estoy haciendo un ejemplo), entonces hemos exprimido toda la seguridad. podemos salir de eso No obtenemos nada más que cálidos sentimientos difusos al hacer que las contraseñas sean más largas. Sin embargo, podemos agregar seguridad a través de hashing que ayuda a mitigar las malas prácticas de contraseña (cuando tienen más de 72 caracteres).