¿El tiempo de espera de una sesión hace que una aplicación sea más segura en una clave A + HTTPS / sesión aleatoria?

El tiempo de espera de sesión puede prevenir o mitigar varios tipos de ataques. Lo siguiente viene a la mente.

Estación de trabajo no segura. Boss deja su escritorio para almorzar, el empleado se sienta y se da un aumento.

Dispositivos compartidos. Donald Trump usa un iPad de cortesía en el Resort Mar-a-la-go. Terrorista es capaz de obtener iPad después. Obtiene códigos nucleares.

Fuerza bruta. El ataque FREAK reduce la encriptación SSL / TLS a 512 bits; El conjunto de servidores que contiene 1,000 juegos PS-4 craquea la clave en poco más de 31 minutos.  Solo aquellos sitios con una sesión de 30 minutos escapan de una catástrofe.

Robo de identificador de sesión El troyano Odd Job infecta los navegadores de todo el mundo y envía las claves de la sesión a un pirata informático ubicado en Hoboken, Nueva Jersey. Hacker tiene todo el tiempo del mundo para examinar las claves cosechadas y usarlas para propósitos nefarios. Algunas de las claves ya no funcionarán cuando llegue a ellas, aquellas con tiempo de espera de sesión.

CSRF. Hacker envía un millón de correos electrónicos con un GIF divertido que enlaza a https://www.wellsfargo.com/Transfer.aspx?ToAccount=1234&Amount=100000 . Del millón de destinatarios de correo electrónico, 10,000 los abren. De ellos, 100 todavía están conectados a Wellsfargo porque el tiempo de espera de su sesión es demasiado largo. Hacker obtiene millones de $$$, se retira en Costa Rica, donde ahora pasa el tiempo publicando en Stack Exchange.

Si no implementas el tiempo de espera de sesión, eres más vulnerable a todos los tipos de ataques anteriores. El uso de una conexión HTTPS y / o el uso de un identificador de sesión criográfico y aleatorio son pasos buenos e importantes, pero ninguno de los dos salvó a nadie en los ataques anteriores.

Solo usted puede decidir si el riesgo de los ataques anteriores es lo suficientemente importante como para compensar los inconvenientes adicionales para el usuario final. Si es solo una aplicación social, tal vez no. Si es una aplicación bancaria, casi seguro que sí.

Hay una compensación entre la facilidad de uso y la seguridad. Deberá tomar las decisiones apropiadas según la forma en que sus usuarios interactúan con su sitio y su evaluación de amenazas de lo que sucedería si un usuario no autorizado tuviera acceso a su cuenta (después de haber dejado de iniciar sesión después de muchos minutos de inactividad). / p>

Por ejemplo, si el usuario típico desea permanecer conectado durante varias horas con largos períodos de inactividad intercalados, por ejemplo, con un programa de correo web, una aplicación de chat grupal (por ejemplo, IRC, slack), una plataforma de medios sociales (por ejemplo, , facebook / instagram / twitter), entonces no tendría sentido forzarlos a cerrar la sesión después de cinco minutos de inactividad. El cierre de sesión forzado que requiera iniciar sesión repetidamente frustraría a los usuarios que migrarían a otras plataformas.

Por otro lado, si usted es un banco y los usuarios normalmente se registran para hacer algo rápido (por ejemplo, consultar un saldo, pagar una factura o transferir dinero) y rara vez se quedan por largos períodos de tiempo, es perfecto tiene sentido cerrar sesión después de unos minutos de inactividad.

También tiene sentido pensar en los peores escenarios. Si alguien sale de su casa mientras aún está registrado en su cuenta bancaria en su computadora, un ladrón que irrumpe en su casa podría transferir sus ahorros de la vida a una cuenta que controlen. Mientras tanto, si alguien sale de su casa mientras todavía está conectado a su cuenta de redes sociales, puede sentirse un poco avergonzado (y tener que explicar que su cuenta fue pirateada).

También puede haber escenarios en los que la amenaza de uso no autorizado sea tan grande que cada vez que se lleve a cabo esa acción debe autenticarse. Por ejemplo, antes de cambiar su contraseña, siempre necesita que el usuario vuelva a autenticarse. O antes de retirar su carrito en una tienda electrónica (especialmente para productos digitales que no pueden devolverse), puede que siempre obligue al usuario a autenticarse.

Los bancos utilizan autenticación de 2 factores. Ese segundo factor, un token o lo que sea, es diferente a una contraseña que no es algo que un usuario pueda almacenar permanentemente en su administrador de contraseñas. Por lo tanto, se requiere que un usuario, después de un cierto tiempo de inactividad, se vuelva a identificar.

Cuando se usa solo la autenticación de nombre de usuario / contraseña, tiene mucho menos sentido, ya que generalmente en estos días los navegadores o las herramientas externas almacenan las credenciales básicas de los usuarios. Molestar a los usuarios con una pantalla que solo requiere que envíen un formulario precargado no aumenta la seguridad. No es más que molestar a sus usuarios finales.

Sin embargo, es importante que los ID de sesión no puedan ser forzados por la fuerza bruta. A menos que esté creando su propio esquema de autenticación, los marcos de hoy en día probablemente tendrán identificadores de sesión aleatorios que no se pueden adivinar a las pocas semanas del forzamiento brutal.