3

JSON Web Token seems to be a very good tool to authenticate users. But I wonder if an attacker can take the token used by another user and use it for his own attacks.
And to be more precise what makes this method more secure.

S.L. Barth
  • 5,504
  • 8
  • 39
  • 47
Yazid
  • 73
  • 6
  • Glancing at the specs, it does seem to have some protection against replay attacks. – S.L. Barth Apr 30 '15 at 15:28
  • you include the jwt in the header of each request. so anyone who have this token with a valid expiration date can have access to ressources. am i right, or i'm misunderstanding the specs. – Yazid Apr 30 '15 at 15:39

2 Answers2

2

You can prevent replay attacks in JWT by specifying the following claims in your JWT: jti (unique identifier), exp (expiration time) and iat (creation time). The JWT spec clearly states that jti claim can be used to prevent a JWT token to be replayed. From the spec:

The "jti" (JWT ID) claim provides a unique identifier for the JWT. The identifier value MUST be assigned in a manner that ensures that there is a negligible probability that the same value will be accidentally assigned to a different data object; if the application uses multiple issuers, collisions MUST be prevented among values produced by different issuers as well. The "jti" claim can be used to prevent the JWT from being replayed. The "jti" value is a case- sensitive string. Use of this claim is OPTIONAL.

Community
  • 1
Rahil Arora
  • 4,307
  • 2
  • 23
  • 41
1

Actually there was a recent flaw found in JWTs.

If you are using node-jsonwebtoken, pyjwt, namshi/jose, php-jwt or jsjwt with asymmetric keys (RS256, RS384, RS512, ES256, ES384, ES512) it will allow an attacker to create their own "signed" tokens with whatever payload they want, allowing arbitrary account access on some systems.

If the JWT is stored in a cookie, other attacks that are possible include most of the ones with cookies in general. For example, session fixation or not correctly using the Secure or HTTP Only flags. Less likely session fixation though because JWTs tend to include username in the claim, however depending on the system a type of attack similar to login CSRF may be possible.

you include the jwt in the header of each request. so anyone who have this token with a valid expiration date can have access to ressources. am i right, or i'm misunderstanding the specs.

This depends on what is in the claim. A valid expiration date on its own is useless, it needs to include a valid username too of which the signature confirms has not been tampered with.

Community
  • 1
SilverlightFox
  • 33,698
  • 6
  • 69
  • 185
  • The flaw mentioned in the linked post doesn't pertain to the concept of JWTs itself, but certain libraries capable of handling JWTs. – Anders Oct 02 '15 at 16:21