Uso de datos cifrados en la clave de sesión en lugar de aleatorio

0

Estoy escribiendo una aplicación orientada a servicios (REST) que es (casi) totalmente sin estado: puede autenticarse mediante claves API, pero para la interfaz de usuario web usa la sesión donde almacena nada más que la ID de un usuario autenticado (int). La ID de sesión se genera de forma aleatoria, como es habitual ver, las ID de usuario nunca se exponen a los usuarios, ya que los usuarios siempre hacen referencia a ellos con su nombre de usuario

Aquí está la idea que tengo. ¿Qué pasaría si en lugar de asignar un ID de sesión aleatorio lo generaría de la siguiente manera?

N1 bytes aleatorios que no incluyen el byte de bandera + byte de bandera + ID de usuario + byte de bandera + N2 bytes aleatorios;

o, en otras palabras, N bytes aleatorios que contienen una ID escaneable en algún lugar dentro, todos encriptados con la clave secreta del servidor. También es posible usar la IP del cliente como parte de la cadena o como IV, para mitigar el secuestro de sesiones.

El beneficio de este enfoque es que la necesidad de sesión se elimina por completo y, por cuestiones de escalabilidad, solo se requiere que todos los nodos utilicen la misma clave secreta (la replicación de la sesión tampoco es necesaria). Con respecto al rendimiento, no estoy seguro de si el descifrado en memoria (digamos, AES de 128 bits) sería más rápido o más lento que leer los datos de sesión del disco y podarlos de vez en cuando. El único vector de ataque que se me ocurre es que el atacante cree dos cuentas seguidas (de modo que las ID sean secuenciales) y las refuerce de manera bruta en sus dos ID de sesión para obtener la clave secreta (lo cual, creo, no sería factible si fuera efectivamente largo) .

Lo que quiero preguntar es:

  • ¿Qué piensas acerca de la seguridad de tal enfoque? (Me preocupa, ya que las únicas recomendaciones que he visto hasta ahora es "usar un fuerte aleatorio para los ID de sesión", y nunca lea acerca de tal enfoque de ID de sesión encriptado, pero eso podría ser simplemente gente realmente interesada en usar la sesión para almacenar datos allí) ;
  • ¿Cuáles son las posibles formas de criptoanálisis más allá de la descrita?
  • ¿Cuáles son las desventajas, más allá de la posible ID de sesión larga?
  • ¿Es un enfoque conocido (entonces, dónde está documentado?)
pregunta Actine 18.05.2014 - 20:56
fuente

1 respuesta

0

El cifrado es la herramienta incorrecta, porque debe evitar que los usuarios cambien los datos de la sesión, no que los lean. La ID de usuario no es un secreto, pero sería un desastre si las personas pudieran cambiarlo a lo que quieran.

En otras palabras, debe imponer la integridad y autenticidad de los datos de la sesión. El cifrado generalmente no puede hacer esto. Lo que quieres es un HMAC, y marcos como Ruby on Rails en efecto adopta este enfoque .

Sin embargo, un HMAC es mucho más difícil de entender que un simple ID aleatorio, y las sesiones del lado del cliente tienen un par de problemas inherentes. Por ejemplo, si se filtra la clave de la sesión, cualquiera puede forjar cualquier sesión. Tampoco puedes simplemente terminar una sesión. Y por último, pero no menos importante, las sesiones del lado del cliente son vulnerables a los ataques de reproducción, es decir, el usuario puede revertir los cambios que realice en los datos de la sesión simplemente usando la cookie anterior.

    
respondido por el Fleche 18.05.2014 - 21:43
fuente

Lea otras preguntas en las etiquetas