4 ms·

Spec writers and library authors are human? Who knew

tptacek 4mo ago
I don't understand what this is meant to communicate. The standard is either good or it isn't. "Good effort" is not an engineering assessment.
- ForHackernews 4mo ago
  Your objection is that they should be "designing it right from the beginning" but that applies to all realms of endeavour. The reason they didn't is human frailty. If everyone simply designed everything right from the beginning we would live in nirvana.
  - tptacek 4mo ago
    You've completely missed my point. I don't even accept the premise of the JWT standard. But the eventual migration to safer default settings, in a format that continues to expend implementation effort to support settings nobody should use, is in fact a practical engineering problem with the standard.
    - ForHackernews 4mo ago
      And they've published updates[0] and libraries have hardened their defaults and removed support for insecure values (e.g. alg='none'). I'm not sure what more you want? I'd rather use a refined, battle-tested standard with lots of eyes on it than some new untested contender produced by a handful of upstarts ("look, we just designed it right from the beginning! This time it's perfect!") PASETO reeks of second-system syndrome. [0] https://www.rfc-editor.org/info/rfc8725/ https://www.rfc-editor.org/info/rfc8725/
      - tptacek 4mo ago
        I don't recommend PASETO either.
        doc_ick 4mo ago
        What do you recommend then? What technology has been designed, completed, then used for years without any updates or problems?
        kasey_junk 4mo ago
        Bearer tokens are a dead end? You have to validate them anyway so traditional auth is the fallback.
        tptacek 4mo ago
        https://fly.io/blog/api-tokens-a-tedious-survey/ https://fly.io/blog/api-tokens-a-tedious-survey/ tl;dr: most of the time you should use opaque random strings.
        ForHackernews 4mo ago
        API tokens are a very small narrow part of the authorization universe. Having a shared secret relies on a trust relationship between the resource server and the identity provider that does not exist between, say, my SaaS backend and Google or Meta's login system.
        unscaled 4mo ago
        The OP was talking about sessions (which include session cookies and API tokens). I'd argue these use cases are far more common for the average programmer than tokens and signatures that are used for federation, but I'll bite the bullet here: JWT is a serviceable solution for service trust and federation. This use case often just requires a very-short-term token, so lack of revocation support is not an issue. Replay attacks are still an issue, but they can also be prevented with single-use nonces that are included in the token claims. The OP's take (and my take as well) is that JWT is rarely the BEST solution for this use case. You kinda have to use it if you need to implement a standard that mandates JWT such as OpenID Connect. But OpenID Connect is a great example for a place where JWT was used, but was never really necessary. If you do use the authorization code flow securely (on the server side, with a strong client secret and proper CSRF protection) you don't need the ID token. In fact, you don't need to use any cryptography at all! Just like random session IDs, you've got a stateful solution that works reliably without any cryptography. If you cannot do a series of authenticated network requests between HTTPS endpoints to verify trust, then a signed payload could be useful, but you've got better standards than JWS/JWT for that. That's all.
  - andai 4mo ago
    I read an article about business which had this classification, "Would be weird if it worked", "Might work", and "Would be weird if it didn't work" and argued that you want to be in the last category. In engineering we aspire to a slightly stronger standard: "I made it physically impossible to fuck this up."
    - ForHackernews 4mo ago
      And yet https://en.wikipedia.org/wiki/Hyatt_Regency_walkway_collapse#/media/File:HRWalkway.svg https://en.wikipedia.org/wiki/Hyatt_Regency_walkway_collapse...
      - andai 4mo ago
        Yeah I don't think they were aspiring to that
henryoman 4mo ago
Not for long
unscaled 4mo ago
PASETO and TLS 1.3 were also written by humans. TLS libraries (which are several orders of magnitude more complicated than JWT libraries) are also written by humans. If you passionately care about security and misuse-resistance you CAN write a spec that will lead to fewer implementation issues.
- ForHackernews 4mo ago
  You must be young if you're pointing to TLS libraries as an example of doing it right and not getting into trouble with insecure implementations and downgrade attacks. https://wiki.freebsd.org/LibreSSL https://wiki.freebsd.org/LibreSSL
  - unscaled 4mo ago
    I wish I was young. Did I explicitly said TLS __1.3__ or did I not? A lot of effort was put into making TLS 1.3 a stronger, less agile and more misuse-resistant standard than its previous iterations. And that effort worked.

I don't understand what this is meant to communicate. The standard is either good or it isn't. "Good effort" is not an engineering assessment.

ForHackernews 4mo ago
Your objection is that they should be "designing it right from the beginning" but that applies to all realms of endeavour. The reason they didn't is human frailty. If everyone simply designed everything right from the beginning we would live in nirvana.
- tptacek 4mo ago
  You've completely missed my point. I don't even accept the premise of the JWT standard. But the eventual migration to safer default settings, in a format that continues to expend implementation effort to support settings nobody should use, is in fact a practical engineering problem with the standard.
  - ForHackernews 4mo ago
    And they've published updates[0] and libraries have hardened their defaults and removed support for insecure values (e.g. alg='none'). I'm not sure what more you want? I'd rather use a refined, battle-tested standard with lots of eyes on it than some new untested contender produced by a handful of upstarts ("look, we just designed it right from the beginning! This time it's perfect!") PASETO reeks of second-system syndrome. [0] https://www.rfc-editor.org/info/rfc8725/ https://www.rfc-editor.org/info/rfc8725/
    - tptacek 4mo ago
      I don't recommend PASETO either.
      - doc_ick 4mo ago
        What do you recommend then? What technology has been designed, completed, then used for years without any updates or problems?
        kasey_junk 4mo ago
        Bearer tokens are a dead end? You have to validate them anyway so traditional auth is the fallback.
        tptacek 4mo ago
        https://fly.io/blog/api-tokens-a-tedious-survey/ https://fly.io/blog/api-tokens-a-tedious-survey/ tl;dr: most of the time you should use opaque random strings.
        ForHackernews 4mo ago
        API tokens are a very small narrow part of the authorization universe. Having a shared secret relies on a trust relationship between the resource server and the identity provider that does not exist between, say, my SaaS backend and Google or Meta's login system.
        unscaled 4mo ago
        The OP was talking about sessions (which include session cookies and API tokens). I'd argue these use cases are far more common for the average programmer than tokens and signatures that are used for federation, but I'll bite the bullet here: JWT is a serviceable solution for service trust and federation. This use case often just requires a very-short-term token, so lack of revocation support is not an issue. Replay attacks are still an issue, but they can also be prevented with single-use nonces that are included in the token claims. The OP's take (and my take as well) is that JWT is rarely the BEST solution for this use case. You kinda have to use it if you need to implement a standard that mandates JWT such as OpenID Connect. But OpenID Connect is a great example for a place where JWT was used, but was never really necessary. If you do use the authorization code flow securely (on the server side, with a strong client secret and proper CSRF protection) you don't need the ID token. In fact, you don't need to use any cryptography at all! Just like random session IDs, you've got a stateful solution that works reliably without any cryptography. If you cannot do a series of authenticated network requests between HTTPS endpoints to verify trust, then a signed payload could be useful, but you've got better standards than JWS/JWT for that. That's all.
- andai 4mo ago
  I read an article about business which had this classification, "Would be weird if it worked", "Might work", and "Would be weird if it didn't work" and argued that you want to be in the last category. In engineering we aspire to a slightly stronger standard: "I made it physically impossible to fuck this up."
  - ForHackernews 4mo ago
    And yet https://en.wikipedia.org/wiki/Hyatt_Regency_walkway_collapse#/media/File:HRWalkway.svg https://en.wikipedia.org/wiki/Hyatt_Regency_walkway_collapse...
    - andai 4mo ago
      Yeah I don't think they were aspiring to that

henryoman 4mo ago

Not for long

unscaled 4mo ago

PASETO and TLS 1.3 were also written by humans. TLS libraries (which are several orders of magnitude more complicated than JWT libraries) are also written by humans. If you passionately care about security and misuse-resistance you CAN write a spec that will lead to fewer implementation issues.

ForHackernews 4mo ago
You must be young if you're pointing to TLS libraries as an example of doing it right and not getting into trouble with insecure implementations and downgrade attacks. https://wiki.freebsd.org/LibreSSL https://wiki.freebsd.org/LibreSSL
- unscaled 4mo ago
  I wish I was young. Did I explicitly said TLS __1.3__ or did I not? A lot of effort was put into making TLS 1.3 a stronger, less agile and more misuse-resistant standard than its previous iterations. And that effort worked.