8 ms·

I've read so many of these anti-JWT articles, and I don't think I've ever come across a single reasonable complaint against them. What is wrong with people? I'

I've read so many of these anti-JWT articles, and I don't think I've ever come across a single reasonable complaint against them. What is wrong with people? 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. >> Let’s say that your website gets roughly 100k page views per month. That means you’d be consuming an additional ~24MB of bandwidth each month. Negligible. >> You’re Going to Hit the Database Anyway Yes, but less often. So your DB will be able to service more users overall. For some use cases, we're talking orders of magnitude more users.

danenania 8y ago
Inability to do immediate revocations is a real drawback and a valid complaint. If a trusted machine with a privileged token on it is compromised somehow, it will likely take the attacker some time to search for and discover the token. If you use centralized auth and you realize there was a breach before this happens (say from monitoring/anomaly alerts), you can revoke the token and prevent unauthorized access. If your token is JWT and it doesn't expire for another 45 minutes, you're in much worse shape. This isn't the only factor to consider, but it's an important one.
- mathnmusic 8y ago
  Inability to do immediate revocations comes with all stateless, signed tokens (for eg: the way Rails uses cookies). I don't understand why JWT gets the bulk of these criticism when signed stateless cookies are quite prevalent.
CiPHPerCoder 8y ago
> 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

danenania 8y ago

Inability to do immediate revocations is a real drawback and a valid complaint. If a trusted machine with a privileged token on it is compromised somehow, it will likely take the attacker some time to search for and discover the token. If you use centralized auth and you realize there was a breach before this happens (say from monitoring/anomaly alerts), you can revoke the token and prevent unauthorized access. If your token is JWT and it doesn't expire for another 45 minutes, you're in much worse shape. This isn't the only factor to consider, but it's an important one.

mathnmusic 8y ago
Inability to do immediate revocations comes with all stateless, signed tokens (for eg: the way Rails uses cookies). I don't understand why JWT gets the bulk of these criticism when signed stateless cookies are quite prevalent.

CiPHPerCoder 8y ago

> 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