3 ms·

> I've even read security reports by supposedly reputable security consultants also claiming that JWTs are bad but their arguments are hand wavy and make no sen

> I've even read security reports by supposedly reputable security consultants also claiming that JWTs are bad but their arguments are hand wavy and make no sense. https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/ https://auth0.com/blog/critical-vulnerabilities-in-json-web-... https://blogs.adobe.com/security/2017/03/critical-vulnerability-uncovered-in-json-encryption.html https://blogs.adobe.com/security/2017/03/critical-vulnerabil... These were critical vulnerabilities enabled by an error-prone cryptographic design that broke real systems. Don't pretend it's hand-wavy.

jondubois 8y ago
These are vulnerabilities in specific implementations of JWT. It doesn't make JWT unsafe as a whole.
- CiPHPerCoder 8y ago
  > These are vulnerabilities in specific implementations of JWT. No, these are vulnerabilities in the standard itself. I outlined the arguments here: https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba... It's an error-prone cryptographic design that needs to be replaced. Blaming implementations for faithfully implementing a flawed standard is a stupid thing to do, since it doesn't solve their insecurity.
  - jondubois 8y ago
    It definitely was an implementation issue. The JWS spec (which is explicitly referenced in the JWT spec) states clearly under section 4.1.1: 'The JWS Signature value is not valid if the "alg" value does not represent a supported algorithm' Even if you did consider it a flaw in the RFC itself, the fact that there was a flaw once-upon-a-time with a specific aspect of JWT, doesn't invalidate the whole idea of JWTs. I don't know any major standard that was perfect from day 1. This can be said about TCP/IP (e.g. IpV4 addresses were clearly a mistake). Also, I recall that there were flaws with HTTP1 and that's why HTTP1.1 was released soon after. The WebSocket protocol also went through MANY iterations. There are use cases were JWTs are necessary. For example, I did some work with real-time presence (to get notifications when users go online or offline); to be able to get the username from the JWT instead of the database saves a lot of database queries and the code is much cleaner since you can check synchronously instead of having to wait. Also, you don't want to waste precious CPU time doing DB queries for connections that haven't been authenticated yet.
    - CiPHPerCoder 8y ago
      > Even if you did consider it a flaw in the RFC itself, the fact that there was a flaw once-upon-a-time with a specific aspect of JWT, doesn't invalidate the whole idea of JWTs. The premise that went into JWTs was not invalidated. Their design was proven by multiple incidents to be error-prone, so I sought to replace JWTs. The result? https://paseto.io https://paseto.io

jondubois 8y ago

These are vulnerabilities in specific implementations of JWT. It doesn't make JWT unsafe as a whole.

CiPHPerCoder 8y ago
> These are vulnerabilities in specific implementations of JWT. No, these are vulnerabilities in the standard itself. I outlined the arguments here: https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba... It's an error-prone cryptographic design that needs to be replaced. Blaming implementations for faithfully implementing a flawed standard is a stupid thing to do, since it doesn't solve their insecurity.
- jondubois 8y ago
  It definitely was an implementation issue. The JWS spec (which is explicitly referenced in the JWT spec) states clearly under section 4.1.1: 'The JWS Signature value is not valid if the "alg" value does not represent a supported algorithm' Even if you did consider it a flaw in the RFC itself, the fact that there was a flaw once-upon-a-time with a specific aspect of JWT, doesn't invalidate the whole idea of JWTs. I don't know any major standard that was perfect from day 1. This can be said about TCP/IP (e.g. IpV4 addresses were clearly a mistake). Also, I recall that there were flaws with HTTP1 and that's why HTTP1.1 was released soon after. The WebSocket protocol also went through MANY iterations. There are use cases were JWTs are necessary. For example, I did some work with real-time presence (to get notifications when users go online or offline); to be able to get the username from the JWT instead of the database saves a lot of database queries and the code is much cleaner since you can check synchronously instead of having to wait. Also, you don't want to waste precious CPU time doing DB queries for connections that haven't been authenticated yet.
  - CiPHPerCoder 8y ago
    > Even if you did consider it a flaw in the RFC itself, the fact that there was a flaw once-upon-a-time with a specific aspect of JWT, doesn't invalidate the whole idea of JWTs. The premise that went into JWTs was not invalidated. Their design was proven by multiple incidents to be error-prone, so I sought to replace JWTs. The result? https://paseto.io https://paseto.io