Importancia de un corto tiempo de caducidad en JWTs

Question

Importancia de un corto tiempo de caducidad en JWTs

#1 de ApertureSecurity (1 votos)
#2 de Graham Wager (1 votos)

2

Actualmente estamos utilizando tokens web JSON para la autenticación de la API de nuestro sitio web. Usamos tokens de acceso de corta duración de 1 hora que se actualizan con un token de actualización revocable permanente.
Ahora queremos agregar un sistema de cuenta + inicio de sesión al sitio web y vincularlo al uso de la API. Sin embargo, actualmente estamos debatiendo sobre la seguridad de esto.

La implementación ingenua sería solo un token de acceso de 3 horas para una sesión y algo así como un tiempo de expiración de 2 semanas si el usuario elige la opción "permanecer conectado". Sin embargo, esto haría un poco inútil el corto tiempo de caducidad. En caso de que las fichas se filtren, tienes una ventana de ataque de dos semanas completas.
La alternativa que pensamos sería algún tipo de "proxy" que verifique si el token está vencido y se actualiza automáticamente con el token de actualización en localstorage o como una cookie.

¿La versión ingenua sería una implementación aceptable o los riesgos de seguridad son demasiado altos?

web-application authentication account-security jwt

pregunta nn3112337 18.02.2018 - 21:24

fuente

2 respuestas

Lea otras preguntas en las etiquetas web-application authentication account-security jwt

Stagefright - construyendo una pila de ROP - girando Qué hacer con las contraseñas comprometidas a través de sitios maliciosos o hacks de sitios [duplicado]

score 1 · Answer 1

Depende de los requisitos del host y la red en la que se encuentre.

Al igual que con cualquier contraseña JWT / cookie o lo que sea, cuanto más tiempo esté disponible el elemento sin cambiar, más tiempo tendrá un hacker para que se rompa.

Personalmente, he generado el secreto de mis JWT con una clave aleatoria al iniciar la aplicación web.

Establecí una vida útil en JWT de no más de 5 horas. También puede buscar otros elementos en la cookie, como el sistema operativo, el navegador, la dirección IP, etc. Depende de cómo quieras manejarlo.

También puede hacer que todos los JWT se maten al final de las horas de oficina.

El token de acceso de 3 horas para una sesión y algo así como el tiempo de caducidad de 2 semanas si el usuario elige la opción "permanecer conectado". Sin embargo, esto haría que el tiempo de caducidad corto fuera inútil.

Estoy de acuerdo. Alentar a los usuarios a utilizar Lastpass o Keypass puede ser una opción. Personalmente, creo que iniciar sesión una vez cada 5 horas no es un inconveniente y es un costo barato para hacer negocios.

Avísame si esto responde a tu pregunta o si te ayuda.

score 1 · Answer 2

Tenía inquietudes similares cuando observaba pasar de sesiones con estado a la autenticación basada en token.

Queríamos un escenario similar a la validez actual de "20 minutos desde la última solicitud", por lo que decidimos lo siguiente:

Al iniciar sesión, generamos un token válido durante 20 minutos y lo enviamos al usuario. Para solicitudes posteriores, validamos ese token y, si han transcurrido más de 5 minutos desde su creación, continuamos creando un nuevo token de 20 minutos y se lo enviamos al usuario.

Estos tokens tenían 2 secretos aleatorios cifrados en ellos, uno para la aplicación y otro para el usuario (almacenados en la base de datos junto con el registro del usuario). Se comprobó la aplicación uno en cada solicitud, y se comprobó el usuario uno cada vez que se debía renovar un token (por lo tanto, como máximo cada 5 minutos).

Si el usuario tiene alguna inquietud, puede cerrar todas las sesiones o cambiar su contraseña. Ambas acciones generarían un nuevo secreto de usuario, lo que significa que, como máximo, un token antiguo solo sería válido durante 5 minutos. Si hubiera un problema grave, podríamos cambiar el secreto de la aplicación e invalidar inmediatamente todos los tokens existentes.