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.

2
  • Glancing at the specs, it does seem to have some protection against replay attacks. Apr 30, 2015 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, 2015 at 15:39

2 Answers 2

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.

2
  • so the only thing left is to ensure the security of the transmission of the token am i right?
    – Yazid
    May 4, 2015 at 8:56
  • Yes. TLS is your friend. May 4, 2015 at 23:18
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.

1
  • 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 2, 2015 at 16:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .