11

I am trying to understand JWT, and surfing various resource on web. I found the code showing how to check whether JWT is tempered -- this is a great one and I understand it.

However, I don't understand how JWT won't be used by a middle-man who can either look at the browser data (think of a public computer in library) or sniff the wire (I guess this can be avoided by HTTPS though) to get the GWT string, and replay from another computer.

https://float-middle.com/json-web-tokens-jwt-vs-sessions/

[headerB64, payloadB64, signatureB64] = jwt.split('.');

if (atob(signatureB64) === signatureCreatingFunction(headerB64 + '.' + payloadB64) {  
    // good
} else
    // no good
}
chen
  • 4,302
  • 6
  • 41
  • 70
  • 4
    Yes, HTTPS is required to prevent man-in-the-middle attacks when using bearer tokens. – MvdD Jun 24 '16 at 18:15
  • 1
    So just to enhance my knowledge, if tokens can be sniffed off and used in replay, what value do they add if we are to send userid and password instead? There should be some value to them since it is being used in the industry, and so if thats the case what is the value? – Rohan Bhale Jun 28 '20 at 15:19

1 Answers1

8

Indeed, they can. You can take steps to prevent this by, say, encapsulating the requester's IP-address in the encrypted data, and by giving the token a relatively short time-to-live. But, the key idea is that the receiving system has only the token, and its encrypted content, to act upon. The server can verify that the token is valid and know that it has not been altered, but, since there are no "sessions," it will not be able to detect a replay attack unless the content of the token enables it to do so. (Therefore, do so!)

Mike Robinson
  • 8,490
  • 5
  • 28
  • 41
  • 1
    who should be doing the IP-address embedding? It seems to be GWT token provider (Facebook, Google etc.) should be doing so by embedding the IP-of-client in a claim field. However, GWT token providers (e.g., FB/Google) is not doing so as of today, right? Can the resource provider (API service owner) instruct Google/Facebook to issue what claims should be in the tokens? – chen Jun 24 '16 at 17:51
  • You typically have no control over the claims in the token. – MvdD Jun 24 '16 at 18:16
  • I think that, pragmatically speaking, if you want to prevent a token from being swiped out-of-the-air, you're going to have to use SSL or some other form of cryptography to secure the link. Which you probably should be doing anyway. The key concept of this stratagem is very much that of POSSESSION. "You have it or you don't," and anyone who DOES "have it" is going to be recognized. That's simply how the design was done. – Mike Robinson Jun 24 '16 at 21:57
  • 1
    SSL traffic can still be sniffed and tokens can be stolen. There are no real solutions to that in JWT. Expiration doesn't help because the attacked can probably steal the fresh token. I've seen posts from auth0 or oauth.io about using AI to determine unusual token usage in APIs. The most promising solution to replay and mitm is a concept called "token binding", and it is already used in the industry where extra security is needed - like banking. It binds the token to the public/private key on the browser. PingIdentity is one provider. https://en.wikipedia.org/wiki/Token_Binding – James O'Brien Oct 01 '18 at 16:49