'Recordarme' combinado con el token de autenticación

Question

'Recordarme' combinado con el token de autenticación

#1 de Steve (3 votos)

8

He desarrollado una aplicación cliente que habla sobre una API REST a un servidor. La forma en que funciona la aplicación es enviar el par de nombre de usuario / pwd en el inicio de sesión inicial al servidor y luego responder con un token de autenticación en la forma de un GUID recién generado.

El cliente utiliza el GUID para hablar con el servidor durante el resto de la sesión (hasta que se borre el almacenamiento local). La página de inicio de sesión requiere la capacidad de permanecer conectado. Para lograr esto, almaceno el token GUID en el almacenamiento local. Si la clave está ahí, se inicia automáticamente la sesión.

Todas las comunicaciones se realizan a través de SSL, por lo que no me preocupa la seguridad de los datos o MITM, pero me preocupa la seguridad del token almacenado en el almacenamiento local.

Algunas preguntas:

¿Debo cifrar más el GUID? ¿Esto me da algo?
¿Es un gran riesgo para la seguridad almacenar el token de autenticación GUID en el almacenamiento local? Vale la pena asegurar?
¿El almacenamiento del token dentro de una cookie mejora el problema?

También pensé en que el servidor genere nuevos tokens con cada nuevo inicio de sesión y reduzca la ventana de ataque, pero eso evitaría que la función "Recordarme" funcione.

authentication cookies

pregunta jaffa 17.12.2013 - 17:53

fuente

1 respuesta

Lea otras preguntas en las etiquetas authentication cookies

¿Cómo administrar los derechos de administración para el personal del servicio de asistencia? es computrace una puerta trasera permanente?

score 3 · Answer 1

¿Cuando dice que GUID es un GUID real según una especificación, o una clave generada aleatoriamente? Si no es aleatorio, ese es el mayor problema, ya que la seguridad de su sesión ahora se basa en algo que se adivina muy fácilmente.

Dado esto, para responder a las otras preguntas que necesita, pregúntese: ¿qué está protegiendo? ¿Contra qué estás protegiendo? ¿Qué tipo de atacantes? ¿Cuánto esfuerzo está usted o ellos dispuestos a poner en él?

Luego, debe considerar que lo que está mirando es proteger una clave en un sistema cliente que es potencialmente hostil. Podrías cifrar la clave de sesión, pero ¿con qué clave? ¿Qué algoritmo? ¿Todos los navegadores soportan los algoritmos necesarios? ¿Cómo proteges esa llave? La mayoría de los navegadores no admiten criptografía, lo que complica mucho las cosas.

Almacenar cosas en el almacenamiento local es mejor / peor / igual que almacenar en una cookie. Por un lado, es mejor porque puede ayudar a proteger contra CSRF porque para obtener acceso a la clave de sesión que necesita para ejecutar dentro de un contexto que puede acceder al almacenamiento local, mientras que se enviará una cookie al servidor en cada solicitud. siempre que la cookie sea válida. Sin embargo, el almacenamiento local nunca fue realmente diseñado para almacenar cosas confidenciales como las claves de sesión, por lo que no necesariamente obtiene la misma protección de nivel que una tienda de cookies en una máquina (dado que el historial es el mismo, las cookies también tuvieron el mismo problema) ). Hoy en día, las cookies también tienen protección contra el acceso desde JavaScript, por lo que XSS no puede hacer cosas divertidas con sesiones como enviar las llaves a otro servidor, mientras que solo se puede acceder al almacenamiento local desde JavaScript.

Una mitigación potencial es utilizar una cookie y un almacenamiento local para crear una especie de clave compuesta, pero también podría haber complicaciones con eso.

También puede actualizar el token de vez en cuando y asegurarse de que se invalide en el servidor para evitar claves de larga duración, pero eso no necesariamente soluciona nada si un usuario solo visita cada pocas semanas.

¿Borrar como barro?