¿Qué tan difícil es romper la porción de sal del hash

Question

¿Qué tan difícil es romper la porción de sal del hash

#1 de Thomas Pornin (3 votos)

0

Escribo una aplicación móvil y necesito autenticar a los usuarios contra el servidor. El lado del servidor está escrito en php. No puedo usar cookies para almacenar SID (ID de sesión), por lo que decidí enviarlas a cada solicitud utilizando el método GET.

Más tarde, decidí que enviar el mismo SID no es lo suficientemente seguro, por lo que decidí usar una nueva cadena en cada solicitud. Server y Mobile client han almacenado la misma cadena aleatoria (llamémosla salt ). Al final de cada solicitud, el servidor envía una cadena aleatoria al cliente móvil y, en la siguiente solicitud, el cliente móvil envía a la versión del servidor el hash de salt + cadena aleatoria . El servidor crea el hash desde salt + cadena aleatoria y lo compara con uno recibido del cliente móvil para autorizarlo.

Ahora mi pregunta es:

Si hubiera un ataque de hombre en el medio, ¿qué tan difícil será romper el hash y encontrar la porción de sal de los hashes?
¿Cómo podría hacerlo más difícil? (p. ej., no usar la fórmula salt + cadena aleatoria , pero salt_1st_half + cadena aleatoria + salt_2nd_half o hashing varias veces según la longitud del nombre de usuario u otros "trucos")

PS: planeo usar la función crypt de php con el algoritmo blowfish en el servidor

EDIT

Decidí que enviar el mismo SID cada vez no es lo suficientemente seguro

¿Por qué? Debido a que transferiré algunos datos confidenciales del usuario (ubicación real, ..), y cualquier persona que capture SID podría cambiar sipmemente estos datos, o usar el SID actual para fingir que es otra persona y podría obtener otros datos confidenciales de la aplicación (y no lo haría). no se trate de ningún error o error de aplicación, ya que un usuario normal con ese SID tendría acceso a estos datos). Es por eso que decidí cambiar SID después de cada solicitud y agregar algunos cálculos y validación de SID.

password-cracking blowfish

pregunta Buksy 17.09.2013 - 23:02

fuente

1 respuesta

Lea otras preguntas en las etiquetas password-cracking blowfish

Java se está ejecutando incluso después de que esté deshabilitado [cerrado] Peligro al abrir correos electrónicos no deseados en el sistema operativo Ubuntu [cerrado]

score 3 · Accepted Answer

Si tu "cadena aleatoria" es realmente una "cadena aleatoria", entonces ninguno de tus trucos puede hacer ningún bien. Para el caso, la sal tampoco mejorará las cosas. Ni el uso de bcrypt (lo que PHP llama "crypt with Blowfish").

De hecho, todos los juegos con sales e iteraciones son solo formas de hacer frente a la debilidad inherente de contraseñas . Las contraseñas son débiles. No pueden evitar ser débiles: encajan en una mente humana. Entonces, mientras los usuarios humanos sean, digamos, humanos , debemos tratar con contraseñas, y como las contraseñas pueden ser forzadas (para la mayoría de los usuarios humanos), debemos aplicar "trucos" que constituyen el ataque Más fuerte. Los dos trucos principales son la lentitud (lo que hace que la función de hash sea inherentemente costosa a través de muchas iteraciones) y las sales (para evitar ataques paralelos y precomputaciones). He escrito extensamente sobre el tema allí .

Sin embargo, si tiene cadenas aleatorias entre una computadora y otra computadora (los teléfonos inteligentes son computadoras), entonces no hay humanos, entonces no hay problema. Una serie suficientemente larga y suficientemente aleatoria derrota la fuerza bruta por su pura aleatoriedad. Las sales y la lentitud no aportan ninguna seguridad adicional: no puede ser fuerza bruta, punto.

(O, dicho de otro modo, si su cadena aleatoria puede ser forzada brutalmente, entonces lo está haciendo muy mal).

Todo se reduce a esta frase tuya:

Más tarde, decidí que enviar el mismo SID cada vez no es lo suficientemente seguro

¿Por qué?

Simplemente, ¿por qué? ¿Por qué no sería "lo suficientemente seguro"?

Puede haber razones buenas y racionales. Pero no puede hacer nada de valor, en el dominio de la seguridad, si no se toma el tiempo de analizar sus requisitos . Defina su seguridad: sus objetivos, los objetivos del atacante, los poderes del atacante, los activos en juego ...

De todos modos, si las comunicaciones entre la aplicación y su servidor necesitan algún tipo de confidencialidad o integridad o autenticidad (supongo que este es el caso, ya que se molesta con la autenticación), entonces no hay escapatoria: use SSL (también conocido como "HTTPS"). Sin SSL, no hay seguridad real. Pero con SSL, las cosas están bien. Puede enviar su "cadena aleatoria" (que en realidad es una cookie de sesión personalizada) tal como está, no será interceptada por terceros, activa o pasiva.