¿Este método para administrar la administración de sesiones sin almacenamiento es seguro?

Question

¿Este método para administrar la administración de sesiones sin almacenamiento es seguro?

#1 de Hector (3 votos)
#2 de symcbean (1 votos)

0

Tengo una aplicación web en la que los usuarios pueden iniciar sesión. Debido a limitaciones técnicas, la aplicación no tiene permitido almacenar ninguna información de sesión en el disco.

Para identificar las solicitudes del mismo usuario sin almacenar las sesiones en el disco, he diseñado el siguiente esquema:

La aplicación tiene un S secreto del lado del servidor largo, generado aleatoriamente, creado en el momento de la instalación. Hay un usuario con un nombre de usuario u y una contraseña p .

Para iniciar sesión, el usuario presenta (u, p) a la aplicación web para la autenticación en el momento t . Si la autenticación es exitosa, envía una cookie c en la respuesta, que contiene Encrypt (u || t, S) . Encrypt en este caso es AES-256 en modo de operación CBC.

Más tarde, cuando llega una solicitud que contiene c , la aplicación descifra el contenido de c con S para obtener u y t . Obviamente, si u no es un usuario válido, la solicitud es rechazada. Además, la solicitud se rechaza si la diferencia entre la hora actual y t es mayor que x . Rechazar la solicitud implica pedirle al cliente que elimine c y redirigir al usuario a la página de inicio de sesión.

Si el usuario envía una solicitud en el momento t + y , como k < = y < = x , la aplicación actualiza c actualizándolo a Cifrar (u || t + y, S) . k se elige para que sea un valor adecuado, como x / 3 .

Cerrar sesión implica simplemente pedirle al navegador que elimine c .

¿Este método de autenticación es seguro?

web-application authentication cookies session-management

pregunta user2064000 11.10.2017 - 17:00

fuente

2 respuestas

Lea otras preguntas en las etiquetas web-application authentication cookies session-management

¿Demasiados usuarios? [cerrado] ¿Cuál es la razón de vincular certificados SSL a un nombre de dominio? [duplicar]

score 3 · Answer 1

En primer lugar, como siempre, ¿por qué intentas rodar el tuyo? Como se señala en los comentarios, algo así como JWT realiza el mismo trabajo.

Una breve mirada sugiere que esto debería funcionar. Aunque sugeriría hacerlo más transparente. En su lugar, podría utilizar el valor de cookie -

username:[Username]&tokengeneratedat:[GenerationTime]&Sig:[Signature]

Esto hace que el desarrollo, la depuración y la inspección del usuario sean mucho más sencillos, ya que los detalles subyacentes están en texto sin formato. Este enfoque también es más flexible, ya que puede hacer cosas como las teclas de ciclo, solo use Generation Time para identificar qué tecla usar.

Sugeriría verificar que el usuario existe en la tabla como mínimo en la actualización de token / idealmente todas las solicitudes para respaldar la revocación de acceso instantáneo.

score 1 · Answer 2

Dejando de lado la restricción un tanto absurda e inexplicable, el mecanismo es básicamente correcto , siempre y cuando no intentes almacenar demasiados datos en la sesión .

Pero como se presentó, es algo insuficiente y está perdiendo el beneficio de escalabilidad de las sesiones del lado del cliente. No ha incluido un mecanismo para verificar si el nombre de usuario descifrado es válido. La verificación de la marca de tiempo proporciona cierta protección, sin embargo, si fuera yo, incluiría controles adicionales para validar que el texto claro es algo que fue cifrado por el servicio, por ejemplo. Json codifica y comprime antes del cifrado y viceversa después del descifrado.

Sospecho que esto podría ser más vulnerable al criptoanálisis (el atacante puede saber el texto claro y el texto cifrado) que en una aplicación más convencional del cifrado simétrico. Necesitaría preguntar a alguien que sepa mucho sobre criptografía. Pero esto se mitigaría con el uso adecuado de los vectores de inicialización y el relleno aleatorio dentro del texto claro.