¿Es seguro mi plan de actualización de JWT?

Question

¿Es seguro mi plan de actualización de JWT?

#1 de Steve (21 votos)
#2 de sandeep (-1 votos)

19

Planeo usar JWT para mi sistema de inicio de sesión para dispositivos móviles. No hay un flujo de trabajo estándar real para actualizar tokens JWT que pueda encontrar, así que creé este a continuación. La razón por la que quiero usar JWT es por razones de rendimiento. En lugar de verificar si un usuario es válido con una llamada de base de datos para cada solicitud, confío en el JWT.

Tengo el flujo de trabajo propuesto que quiero implementar en mi aplicación. ¿Es esto aceptablemente seguro? ¿Eficiente? ¿Hay algún problema obvio que esté supervisando? ¿Qué mejoras razonables se pueden hacer?

El usuario inicia sesión

Si no existe un token firmado HMAC dentro de localstorage, el usuario le da un nombre al dispositivo.
DeviceName se envía al servidor donde se inserta en la base de datos.
El token JWT + el token firmado HMAC de DeviceName se devuelven al usuario. El token firmado HMAC se coloca para asegurarse de que el token jwt (que contiene DeviceName) se envíe desde el mismo dispositivo que lo llamó originalmente.
El token JWT es válido durante X horas, por lo que un usuario puede realizar cualquier llamada durante X horas.
Después de X horas, el JWT ha caducado. Cuando se realiza una solicitud, el servidor puede ver que el JWT ha caducado. El servidor ahora intentará actualizar el token JWT. El servidor comprueba la base de datos para ver si el Nombre del dispositivo especificado en el token firmado HMAC es el mismo que el nombre de dispositivo válido en la base de datos para ese usuario.
Si es así, cree un nuevo JWT válido por otras X horas, si no es así, envíe un mensaje para solicitar que inicie sesión.

Si una cuenta está comprometida:

El usuario puede iniciar sesión en mi servicio de contraseña. Una vez que haya iniciado sesión, me gustaría recuperar todos los dispositivos para ese usuario, el usuario puede revocar su dispositivo comprometido. Una vez hecho esto, una solicitud para actualizar el JWT no funcionará con el token robado.

Todo esto, por supuesto, ocurre sobre SSL.

Mis preocupaciones que no tengo soluciones para:

Si se roba un token JWT, el atacante tiene X horas para hacer llamadas según la víctima. ¿Creo que esta es la naturaleza de los tokens y un riesgo aceptado?
Si el JWT es robado, eso significa que existe una buena posibilidad de que el token HMAC que contiene el nombre del dispositivo también sea secuestrado para que el usuario pueda actualizar los tokens hasta que la víctima se dé cuenta de que su cuenta está comprometida y revoque el acceso. ¿Es esta práctica aceptada?

authentication oauth mobile token

pregunta user2924127 08.06.2015 - 23:31

fuente

2 respuestas

-1

La seguridad siempre es relativa y, con más esfuerzos, podemos hacer que sea un paso más difícil para cualquier persona abusar del sistema. Los tokens de portador están enlazados a IO (caché / llamada de base de datos) y los tokens JWT están vinculados a CPU (cifrado / descifrado). Ambas son soluciones lo suficientemente buenas para el mundo de los servicios regulares, excepto por una cosa que estamos tomando aquí sobre los dispositivos móviles. Uno de los métodos que se podrían utilizar aquí es enviar el token / actualizar token al dispositivo a través de backchannel en lugar de enviarlo como parte de la autenticación. Parece algo extra de trabajo, pero ofrece algo más de seguridad en cuanto a la emisión y actualización de tokens para dispositivos móviles. Más detalles se pueden encontrar aquí enlace

respondido por el sandeep 01.11.2016 - 05:58

fuente

Lea otras preguntas en las etiquetas authentication oauth mobile token

Vector de ataque, superficie de ataque, vulnerabilidad, vulnerabilidad: ¿Dónde está la diferencia? Cómo implementar la autenticación sin contraseña en un sitio web

score 21 · Accepted Answer

¿Aceptablemente seguro en el ámbito de qué?

Ha descrito el flujo básico para todas las fichas de portador. Los que llevan la ficha tienen el poder. Tiene una condición en la que verifica si el token ha sido revocado, pero eso significará que el token es válido hasta que caduquen o sean revocados. Esto es básicamente lo mismo que verificar si el usuario es válido en la base de datos, pero está reemplazando al usuario con dispositivo + JWT. Eso está bien, pero no es una gran ganancia de rendimiento.

Otros sistemas utilizan dos JWT (o un JWT y un token opaco). El primer JWT es su token de acceso utilizado principalmente como usted describe, pero no verifica la revocación. Este token es de corta duración, quizás 20 min, > 1h, y luego tienes tu token de actualización que vive considerablemente más tiempo. Cuando su token de acceso caduca, envía el token de actualización y si el token de actualización sigue siendo válido, emite un nuevo token de acceso. Si el token de actualización ha caducado, puede forzar la autenticación nuevamente o simplemente emitir un nuevo token de acceso y actualización.

El valor aquí es que solo necesita validar el token de actualización en la base de datos, y solo debe hacerlo cuando el token de acceso caduque. Cuando el usuario marca el token de actualización como revocado, el token de actualización no le da al atacante un nuevo token de acceso.

La compensación es que no realiza consultas en la base de datos tan a menudo, pero el atacante puede hacer lo que quiera siempre que el token de acceso sea válido. Esto se mitiga con el uso de un token de vida muy corta (es un juego de probabilidades). Si este es un riesgo aceptado es totalmente de usted. No determinamos si debe aceptar el riesgo. :)