authentication - example - jwt issuer

¿Qué pasa si roban JWT?

Question

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

AFAIK, JWT es básicamente una cadena encriptada 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, ¿podrá falsificar una solicitud con mi identidad?

En realidad, esta preocupación se aplica a toda la autenticación basada en token .

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

Answer 1

Lamento llegar un poco tarde en esto, pero tenía las mismas preocupaciones y ahora quiero contribuir con algo igual.

1) agregó un excelente punto, que JWT no tiene nada que ver con la "seguridad" y simplemente valida, si alguien se ha equivocado con la carga útil o no (firma); SSL ayuda a prevenir las infracciones.

2) Ahora, si ssl también se ve comprometido de alguna manera, cualquier espía puede robar nuestra ficha de portador (JWT) y suplantar al usuario genuino, un paso de siguiente nivel que se puede hacer es buscar la "prueba de posesión" de JWT del cliente .

3) Ahora, con este enfoque, el presentador del JWT posee una clave particular de Prueba de Posesión (POP), que el destinatario puede confirmar cryptographically si la solicitud es del mismo usuario auténtico o no.

Remití el artículo Prueba de posesión para esto y estoy convencido con el apporach.

Estaré encantado, si puedo contribuir con algo.

Saludos (y)

Answer 2

Sé que esta es una vieja pregunta, pero creo que puedo dejar mis $ 0,50 aquí, probablemente alguien pueda mejorar o proporcionar un argumento para rechazar totalmente mi enfoque. Estoy usando JWT 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 el reclamo de exp a 30 minutos y ttl a 3 días, por lo que puede actualizar este token siempre que sea ttl sigue siendo válido y el token no ha sido incluido 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 una JWT blacklist / JWT blacklist ban-list frente, dependiendo de algunos criterios: (Sé que rompe el RESTful filosofía, pero los documentos almacenados son realmente de corta duración, ya que incluyo en la lista negra el tiempo restante de vida, según afirman ttl )

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

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

Finalmente, valida el token normalmente como todos lo hacen.

Nota 2: en lugar de usar el token en sí (que es realmente largo) como clave de la memoria caché, sugiero generar y usar un token UUID para el reclamo jti . Lo cual es bueno y creo que (no estoy seguro ya que se me ocurrió) también puede usar este mismo UUID que el token CSRF, devolviendo una cookie secure / non-http-only e implementando correctamente la X-XSRF-TOKEN usando js. De esta forma, evita el trabajo informático de crear otro token para las comprobaciones CSRF.

Answer 3

Soy el autor de una biblioteca de nodos que maneja la autenticación con bastante profundidad, express-stormpath , por lo que express-stormpath con información aquí.

En primer lugar, los JWT generalmente NO están encriptados. Si bien hay una manera de cifrar los JWT (ver: JWEs ), esto no es muy común en la práctica por muchas razones.

A continuación, cualquier forma de autenticación (utilizando JWT o no) está sujeta a ataques MitM (ataques intermedios). Estos ataques suceden cuando un atacante puede VER SU tráfico de 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 prevenir: al encriptar el tráfico de su 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 sean de alguna manera capaces para obtener una copia de la clave SSL privada del servidor (poco probable). Esta es la razón por la que SSL es OBLIGATORIO para todas las formas de autenticación.

Sin embargo, supongamos que alguien puede explotar su SSL y puede ver su token: la respuesta a su pregunta es SÍ , el atacante podrá 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 haya metido con eso (firma).

SIN EMBARGO, los JWT en sí mismos no tienen nada que ver con la ''seguridad''. Para todos los efectos, los JWT son más o menos lo mismo que las claves API: solo cadenas aleatorias que se utilizan para autenticarse en algún servidor en algún lugar.

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

La forma en que funciona OAuth2 es que fue diseñado para dar a los clientes tokens TEMPORALES (¡como JWT!) Para autenticación solo durante un CORTO PERÍODO DE TIEMPO!

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

Con OAuth2, debe volver a autenticarse con el servidor de vez en cuando al proporcionar 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, tus tokens cambian 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 ^^