¿Qué pasa si JWT es robado?

Question

¿Qué pasa si JWT es robado?

Estoy intentando implementar la autenticación sin estado con JWT para mis API RESTful.

AFAIK, JWT es básicamente una cadena cifrada pasada como encabezados HTTP durante una llamada REST.

Pero ¿qué pasa si hay un espía que ve la solicitud y roba el token? Entonces él será capaz de falsa solicitud con mi identidad?

En realidad, esta preocupación se aplica a todos los autenticación basada en tokens.

¿Cómo prevenir eso? ¿Un canal seguro como HTTPS?

94

authentication jwt access-token

Author: smwikipedia, 2015-12-14

Source

2 answers

Sé que esta es una vieja pregunta, pero creo que puedo bajar mis 0 0.50 aquí, probablemente alguien puede mejorar o proporcionar un argumento para rechazar totalmente mi enfoque. Estoy usando JWTs en una API RESTful sobre HTTPS (ofc).

Para que esto funcione, siempre debe emitir tokens de corta duración (depende de la mayoría de los casos, en mi aplicación, en realidad estoy configurando la reclamación exp a 30 minutos y ttl a 3 días, para que pueda actualizar este token siempre que su ttl siga siendo válido y el token en la lista negra )

Para el authentication service, para invalidar tokens, me gusta usar una capa de caché en memoria (redis en mi caso) como un JWT blacklist/ban-list delante, dependiendo de algunos criterios: (Sé que rompe la filosofía RESTful, pero los documentos almacenados son realmente de corta duración, ya que pongo en la lista negra su tiempo de vida restante - ttl reclamo -)

Nota: los tokens de la lista negra no se pueden actualizar automáticamente

Si user.password o user.email ha sido actualizado (requiere confirmación de contraseña), auth service devuelve un token actualizado e invalida (lista negra) uno(s) anterior (s), por lo que si su cliente detecta que la identidad del usuario se ha visto comprometida de alguna manera, puede pedirle a ese usuario que cambie su contraseña. Si no desea utilizar la lista negra para ello, puede (pero no le animo a) validar la reclamación iat (emitida en) contra el campo user.updated_at (si jwt.iat < user.updated_at entonces JWT no es válido).
El usuario ha cerrado sesión deliberadamente.

Finalmente usted valida el token normalmente como todo el mundo lo hace.

Nota 2: en lugar de usar el token en sí (que es realmente largo) como clave de la caché, sugiero generar y usar un token UUID para la reclamación jti. Lo cual es bueno y creo que (no estoy seguro ya que acaba de surgir en mi mente) puede utilizar este mismo UUID como el token CSRF también, devolviendo un secure / non-http-only cookie con él e implementando correctamente el encabezado X-XSRF-TOKEN usando js. De esta manera se evita el trabajo informático de creando otro token para verificaciones CSRF.

10

Author: Frondor,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-08-12 07:15:31

score 164 · Accepted Answer

Soy el autor de una biblioteca de nodos que maneja la autenticación en bastante profundidad, express-stormpath, así que voy a entrar con algo de información aquí.

En primer lugar, los JWT suelen ser NO cifrados. Si bien hay una forma de cifrar JWTs (ver: JWEs), esto no es muy común en la práctica por muchas razones.

A continuación, cualquier forma de autenticación (usando JWTs o no), está sujeta a ataques MitM (man-in-the-middle). Estos ataques ocurren cuando un el atacante puede VER el tráfico de SU RED a medida que realiza solicitudes a través de Internet. Esto es lo que su ISP puede ver, la NSA, etc.

Esto es lo que SSL ayuda a evitar: al cifrar el tráfico de RED desde su computadora -> algún servidor al autenticarse, un tercero que está monitoreando su tráfico de red NO puede ver sus tokens, contraseñas ni nada por el estilo a menos que de alguna manera puedan obtener una copia de la clave SSL privada del servidor (improbable). Esta es la razón por la que SSL es OBLIGATORIO para todas las formas de autenticación.

Digamos, sin embargo, que alguien es capaz de explotar su SSL y es capaz de ver su token: la respuesta a su pregunta es que SÍ, el atacante será capaz de usar ese token para hacerse pasar por usted y hacer solicitudes a su servidor.

Ahora, aquí es donde entran los protocolos.

Los JWT son solo un estándar para un token de autenticación. Se pueden usar para casi cualquier cosa. La razón por la que los JWT son geniales es que puede incrustar información adicional en ellos, y puede validar que nadie se ha metido con él (firma).

SIN embargo, los JWT no tienen nada que ver con la 'seguridad'. Para todos los propósitos, los JWT son más o menos lo mismo que las claves API: solo cadenas aleatorias que se usan para autenticarse contra algún servidor en algún lugar.

Lo que hace que su pregunta sea más interesante, es el protocolo que se está utilizando (muy probablemente OAuth2).

La forma en que funciona OAuth2, es que fue diseñado para dar a los clientes tokens TEMPORALES (como JWTs!) para la autenticación POR UN CORTO PERÍODO DE TIEMPO SOLAMENTE!

La idea es que si su token es robado, el atacante solo puede usarlo por un corto período de tiempo.

Con OAuth2, debe volver a autenticarse con el servidor cada cierto tiempo, proporcionando su nombre de usuario/contraseña O credenciales de API, y luego obtener un token a cambio.

Debido a que este proceso ocurre de vez en cuando, sus tokens cambiarán con frecuencia, lo que hace que sea "más difícil" para los atacantes hacerse pasar constantemente por ti sin pasar por grandes problemas.

Esperemos que esto ayude ^^