5 ms·

JSON web tokens are indeed pretty dope. The main vulnerability I worry about when I see it being used is in the implementation by the end user or library, in t

by MoOmer 11y ago

JSON web tokens are indeed pretty dope. The main vulnerability I worry about when I see it being used is in the implementation by the end user or library, in that you must validate the algorithm used to sign the key [0]; but, many libraries assume that users will read the spec before plopping in a new auth scheme into their app, and don't do this by default. Secondly, it's important to remember that JWTs can be decoded anywhere, but verified as signed by you. I've been using JWT-go [1] in my most recent app, and it's been great. [0]: https://auth0.com/blog/2015/03/31/critical-vulnerabilities-in-json-web-token-libraries/ https://auth0.com/blog/2015/03/31/critical-vulnerabilities-i... [1]: https://github.com/dgrijalva/jwt-go https://github.com/dgrijalva/jwt-go

tracker1 11y ago
JWT actually has two options, you can encrypt the payload, or you can sign it with public/private key. I believe that the path the article uses actually uses the encryption option. I was going to point this out in my own post, but wanted to finish reading the article first. Of course if you go the signed route, you accept the payload is fully readable, and you must confirm the signature for every request.
- k__ 11y ago
  Are you implying that the "encrypted route" doesn't need to be verified on every request?
  - tracker1 11y ago
    You have to decrypt it to read it... you need the key to do that. If you are referring to revoking tokens before expiration, that's a separate issue, and yes it would require a check... but this would be true of any session based system.
    - ebbv 11y ago
      I think the point is regardless of whether you need to decrypt it to read it or not, you should be verifying the content against a signature. Otherwise the content could be forged.
      - eloisius 11y ago
        If you use something like jwt-ruby, you get signature verification out of the box.
      - tracker1 11y ago
        When it's symetrically encrypted, you have the key, it's verified if it decrypts to a valid value. When it's asymetrically signed, you are supposed to verify the signature.
      - tracker1 11y ago
        Seeing a recently posted vulnerability article, I now see your point... which is funny, in practice, I found JWT so easy to implement a naive solution, I only implemented the pieces I needed as my own authority... One time was JWE (encrypted) with a private key, and the other was asymetricly encrypted, not HS256 ... so there wasn't a means to bypass the intended method used by the system. Yes, if you are going to implement/support a number of mixed methods for generating tokens (or a use a client library that does), you absolutely need to confirm that the expected header/signature matches.
- davewritescode 11y ago
  I made some contributions to one of the open source java implementations(https://bitbucket.org/nimbusds/nimbus-jose-jwt https://bitbucket.org/nimbusds/nimbus-jose-jwt) and I believe the encrypted form of JWTs are referred to as JWEs. https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-40 https://tools.ietf.org/html/draft-ietf-jose-json-web-encrypt...
tptacek 11y ago
I emphatically recommend that you not use JSON web tokens for a security problem as straightforward as protecting an API. JWT is a horrible kitchen-sink standard; it is cryptographically terrifying. 99 times out of 100, the problems people try to solve around APIs with cryptography are better solved with simple 256-bit random integer tokens.
- lsb 11y ago
  1) What would your recommendation be if it's not only an API but an ensemble of services that need authentication and authorization? It's feasible to use signed (and maybe encrypted) JWTs for such a purpose, but it'd be interesting to hear your thoughts. 2) To avoid this sort of repeated question, do you have a set of guidelines to avoid common mistakes and generally Do The Right Thing for standard security problems?
  - breischl 11y ago
    This is a little more crypto-oriented, but might be along the lines of what you're looking for. https://gist.github.com/tqbf/be58d2d39690c3b366ad https://gist.github.com/tqbf/be58d2d39690c3b366ad
deleted 11y ago
[deleted]

by MoOmer 11y ago

tracker1 11y ago

JWT actually has two options, you can encrypt the payload, or you can sign it with public/private key. I believe that the path the article uses actually uses the encryption option. I was going to point this out in my own post, but wanted to finish reading the article first. Of course if you go the signed route, you accept the payload is fully readable, and you must confirm the signature for every request.

k__ 11y ago
Are you implying that the "encrypted route" doesn't need to be verified on every request?
- tracker1 11y ago
  You have to decrypt it to read it... you need the key to do that. If you are referring to revoking tokens before expiration, that's a separate issue, and yes it would require a check... but this would be true of any session based system.
  - ebbv 11y ago
    I think the point is regardless of whether you need to decrypt it to read it or not, you should be verifying the content against a signature. Otherwise the content could be forged.
    - eloisius 11y ago
      If you use something like jwt-ruby, you get signature verification out of the box.
    - tracker1 11y ago
      When it's symetrically encrypted, you have the key, it's verified if it decrypts to a valid value. When it's asymetrically signed, you are supposed to verify the signature.
    - tracker1 11y ago
      Seeing a recently posted vulnerability article, I now see your point... which is funny, in practice, I found JWT so easy to implement a naive solution, I only implemented the pieces I needed as my own authority... One time was JWE (encrypted) with a private key, and the other was asymetricly encrypted, not HS256 ... so there wasn't a means to bypass the intended method used by the system. Yes, if you are going to implement/support a number of mixed methods for generating tokens (or a use a client library that does), you absolutely need to confirm that the expected header/signature matches.
davewritescode 11y ago
I made some contributions to one of the open source java implementations(https://bitbucket.org/nimbusds/nimbus-jose-jwt https://bitbucket.org/nimbusds/nimbus-jose-jwt) and I believe the encrypted form of JWTs are referred to as JWEs. https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-40 https://tools.ietf.org/html/draft-ietf-jose-json-web-encrypt...

tptacek 11y ago

I emphatically recommend that you not use JSON web tokens for a security problem as straightforward as protecting an API. JWT is a horrible kitchen-sink standard; it is cryptographically terrifying. 99 times out of 100, the problems people try to solve around APIs with cryptography are better solved with simple 256-bit random integer tokens.

lsb 11y ago
1) What would your recommendation be if it's not only an API but an ensemble of services that need authentication and authorization? It's feasible to use signed (and maybe encrypted) JWTs for such a purpose, but it'd be interesting to hear your thoughts. 2) To avoid this sort of repeated question, do you have a set of guidelines to avoid common mistakes and generally Do The Right Thing for standard security problems?
- breischl 11y ago
  This is a little more crypto-oriented, but might be along the lines of what you're looking for. https://gist.github.com/tqbf/be58d2d39690c3b366ad https://gist.github.com/tqbf/be58d2d39690c3b366ad

deleted 11y ago

[deleted]