¿Existe una desventaja criptográfica al aplicar bcrypt a una contraseña ya hash

Question

¿Existe una desventaja criptográfica al aplicar bcrypt a una contraseña ya hash

#1 de AndrolGenhald (4 votos)
#2 de GxTruth (3 votos)

3

Originalmente pregunté esto en stackoverflow , pero debido a la falta de tracción y una recomendación de un usuario allí, también lo he pedido aquí.

Imagine un escenario en el que una aplicación cliente está enviando una contraseña a un servidor backend para que el servidor pueda validar que el usuario ingresó la contraseña correcta cuando se compara con una variación almacenada de la contraseña.

El mecanismo de transporte es HTTPS con el servidor que proporciona HSTS & HPKP para el agente de usuario y los cifrados criptográficos fuertes son preferidos por el servidor que puntúa A + en la prueba de laboratorio de SSL. No obstante, es posible que deseamos evitar el envío de la contraseña original provista por el usuario al servidor desde el agente del usuario. En su lugar, quizás enviemos un hash después de varias rondas de SHA-256 en el cliente.

En el lado del servidor, para el almacenamiento de contraseñas estamos usando bcrypt con un gran número de rondas.

Desde un punto de vista criptográfico, ¿hay alguna desventaja de realizar bcrypt en el valor hash ya sha-256 en lugar de hacerlo directamente en la contraseña de texto sin formato? ¿La naturaleza de longitud fija del texto de entrada al usar hashes de alguna manera socava las fortalezas del algoritmo?

No pregunto sobre el rendimiento, como la memoria, la CPU, los requisitos de almacenamiento o el tiempo de reloj de pared requerido para calcular, almacenar, enviar o comparar valores. Estoy totalmente interesado en saber si aplicar un hash antes de aplicar bcrypt podría debilitar la fortaleza de bcrypt en el caso de una divulgación de la lista completa de valores almacenados.

He leído publicaciones this (que me parece interesante y útil) pero no estoy preguntando específicamente si es una buena idea hacer hash en el lado del cliente. Estoy más interesado en hacer así podría de alguna manera debilitar el sistema de almacenamiento de contraseñas con bcrypt, dado que un atacante armado con este conocimiento sabría que todos los valores almacenados son un derivado de una longitud fija fija de entradas que consiste en un rango mucho menor de caracteres posibles (SHA-256)

passwords password-management password-cracking bcrypt sha2

pregunta David Goate 11.06.2018 - 10:55

fuente

2 respuestas

4

Mientras que el primer hash no esté horriblemente roto (y me refiero a que esté tan mal que es significativamente peor que el MD5), esto no debilita el bcrypt hash de ninguna manera notable. De hecho, a veces se recomienda realizar una ronda de SHA256 antes de bcrypt porque bcrypt trunca en silencio a 72 caracteres. Si bien 72 caracteres deberían ser más que suficientes para una buena frase de contraseña, el truncamiento silencioso no es lo ideal.

Sin embargo , hay un detalle de implementación importante que must debe tener en cuenta si desea hacer esto. bcrypt fue diseñado para codificar cadenas , no datos , y como tal, usa cadenas terminadas en nulo. Lo que realmente quieres hacer es bcrypt(base64(sha256(password))) en lugar de bcrypt(sha256(password)) , de lo contrario, un 0 byte cerca del frente del sha256 hash sería catastrófico, ya que bcrypt solo incluiría los primeros caracteres.

Si su objetivo es evitar que una MitM pasiva obtenga la contraseña original, es útil hacer sha256 del lado del cliente, sin embargo, no lo protege tanto como cree si su preocupación es una pérdida de la base de datos. Agregar un sha256 antes de bcrypt realmente no cambia nada en términos de tiempo que tomará para descifrar las contraseñas, solo significa que el atacante tiene que hacer sus conjeturas a través de sha256 también, lo que no las frena en absoluto comparado con el uso de un alto costo para bcrypt .

respondido por el AndrolGenhald 11.06.2018 - 16:58

fuente

Lea otras preguntas en las etiquetas passwords password-management password-cracking bcrypt sha2

Carga de archivo PDF malintencionado ¿Cómo puede un servidor de Internet encontrar mi dirección IP local? [duplicar]

score 3 · Accepted Answer

Bueno, en teoría, el uso explícito de las salidas SHA256 como entrada limita la cantidad de entradas posibles, pero el número enorme (!) de salidas SHA256 hace que este sea un factor insignificante. Saber esto no proporciona una ventaja real (hasta donde sabemos hoy), ya que la salida de hash es bastante pseudoaleatoria. No debería haber mucha diferencia entre todas las salidas posibles de SHA256 y las 2 ²⁵⁶ cadenas aleatorias que ingresan a la función. Realmente no se puede derivar un patrón a partir de las salidas (si pudiera, la función hash es mala). No puedo ver ninguna implicación importante desde una perspectiva criptográfica.

Un comentario sobre su escenario, o por qué el hash del lado del cliente no es una mejora en el envío de texto sin formato:

El uso del hashing del lado del cliente evita que un atacante obtenga una contraseña de texto simple, IF (si es enorme, como usted describió muchos estándares de alta seguridad), pueden comprimir la conexión EN ALGUNA PARTE. Sin embargo, el hash de la contraseña antes de enviarla hace que el hash sea la nueva contraseña, ya que a su servidor no le importa si la contraseña proporcionada es un hash o "topSecretK3y".

Si un atacante obtiene este hash, su valor es tan alto como la contraseña original, ya que ahora puede hacerse pasar por la víctima.

P.S .: El único "inconveniente" es que el atacante no puede usar el nombre de usuario / contraseña para otros sitios web, por lo que al menos evita un "ataque de reutilización de contraseña" en otros sitios web.