6 ms·

> The problem with JWT is the user gets to choose which algorithm to use. Only if you completely bungle the implementation on the server-side. The 'none' 'algo

> The problem with JWT is the user gets to choose which algorithm to use. Only if you completely bungle the implementation on the server-side. The 'none' 'algorithm' isn't supported by up-to-date JWT libraries with a good track record, and you should always limit the algorithms you'll allow on the server. So if you sign your tokens with a RSA-2048 key-pair, you would discard any token that isn't using that algorithm. Of course if you are building an API that blindly accepts whatever it receives from a user agent you are bound to create a security gap — but that holds true for anything users send you though, not just JWTs. JSON Web Token is not that hard to grok, and it isn't a 'foot-gun' technology (just practice trigger discipline — i.e., read the documentation). I'm a Java guy, so I'll limit my experience to the libraries available there, but of the four Java libraries available, three provide strict validation of the signing algorithm out of the box, and explicitly document this in their examples and documentation (I think the fourth does too, but I haven't tried that one myself). JSON Web Token is a neat standard that has a lot of good parts that can reliably be used to create and process authentication tokens. So if you are still worried about developers getting it wrong, then instead of saying 'don't use JWT', why not promote a safe subset of the specification instead and promote that? Call it 'iron-jwt' or something. It beats rolling your own solution. Or if you want to be particularly constructive and feel that developers are misusing this technology, write a sensible, short, to the point implementers guide for using JWT and spread the word.

gant 10y ago
OP literally just deleted a bunch of files from the repo and then went out of his way to break compatibility with normal JWT HS256 tokens by changing the typ and removing the alg argument. If you wanted to pull out other algos from jwt-go, deleting their implementations would've been entirely sufficient. There is a map that holds a alg-string to implementation that would've ended up with only HS256. Instead OP made sure these tokens can't be used outside their fork, and thus only in Go. ISHYGDDT.
- skrebbel 10y ago
  > ISHYGDDT For readers like me, this means "I seriously hope you guys don't do this."
  - gant 10y ago
    Working as intended.
  - badosu 10y ago
    Thanks for the information, I find that these acronyms may increase the bandwidth of communication, but the worse quality of the prose and dependence of context that is not always obvious makes this pattern very annoying. I've read this one specifically many times without knowing what it means, whereas the author may think that an interested reader would look up it's meaning, in my case I rejected what I read and moved on.
    - zyx321 10y ago
      ISHYGDDT is 4chan slang. It's deliberately obtuse. You're not supposed to look it up, you're supposed to LURK MORE until you figure it out from context. Even if you do know what it stands for, that's still only half of the true meaning. EDIT: By which I mean this sort of language is not a good fit for an audience that doesn't follow 4chan memes.
      - always_good 10y ago
        Yeah, let's please keep this childish nonsense off of HN. > Even if you do know what it stands for, that's > still only half of the true meaning. I cringed.
        zyx321 10y ago
        >I cringed. Thank you for your valuable contribution.
JimDabell 10y ago
> Only if you completely bungle the implementation on the server-side. Which happens with regularity. This is exactly what led to the vulnerabilities mentioned in the article. This is a bit like arguing against the claim that generating SQL queries by concatenating strings is unsafe. "Only if you completely bungle escaping the parameters", right? As it turns out, that's an extremely common mistake. It's easier to use a known-safe practice like parameterised queries than it is to rely on developers avoiding this pitfall each and every time they have to execute an SQL query. Likewise with this. We know that negotiating the algorithm is subject to mistakes, and it offers no benefits. So instead of relying on developers avoiding this pitfall each time, let's avoid the pitfall altogether and get rid of negotiation. There's a human aspect to security that's being missed here. Saying what boils down to "well developers shouldn't write insecure code" doesn't actually stop developers from writing insecure code. You can point the finger after the fact, but if you want to actually improve security, we need better standards than this.
- Freak_NL 10y ago
  > This is a bit like arguing against the claim that generating SQL queries by concatenating strings is unsafe. "Only if you completely bungle escaping the parameters", right? No, you document how it should be done. Any major database layer using SQL provides parametrised SQL queries, and strongly suggests developers use that (usually in the quick start guide). You can still do your own concatenation, but aren't advised to. The JWT libraries that are up-to-date and well-documented don't recommend blindly trusting the algorithm set in the header either, they recommend safe approaches such as configuring your whitelist and letting any unlisted algorithms fail. For example: https://github.com/auth0/java-jwt#verify-a-token https://github.com/auth0/java-jwt#verify-a-token Only if you completely refuse to read even the basic 'getting started' documentation will you get to this kind of weird vulnerability. The issues with this part of the JWT standard have been addressed by the libraries, what remains is just a little bit of effort on the part of the developer — which may be expected from someone writing security critical code. That is, don't blame the hammer for the shoddy carpentry. > So instead of relying on developers avoiding this pitfall each time, let's avoid the pitfall altogether and get rid of negotiation. So write a concise pamphlet that can easily be shared with all of the JWT libraries in an issue/bug report. If there is a good argument for having to explicitly whitelist algorithms, they might welcome the suggestion. Some libraries already do this mind!
eriknstr 10y ago
>JSON Web Token Thanks, I didn't know what JWT meant. When I first read the title I thought it would be about the Google Web Toolkit (GWT) which I incorrectly remembered as being named Java Web Toolkit (JWT) because with GWT you use Java. Author would do well to edit their post, changing the title to "Things to Use Instead of JSON Web Tokens" and replacing the first occurrence of "JWT" in the body text with "JSON Web Tokens (JWT)". In addition to helping visitors from HN, this change could also improve the possibility for others to find the text in the future when they search for JSON Web Tokens using a search engine.
- mmmpop 10y ago
  To make it more fun, people say JWT as "jot" which sends me into a blind rage.
  - Freak_NL 10y ago
    I can imagine. Unfortunately, "jot" is the formal pronunciation of JWT… Makes me glad me and my colleagues are Dutch; we just pronounce the names of the three letters in Dutch — yaywaytay.
    - mmmpop 10y ago
      I prefer that pronunciation too!
  - devrandomguy 10y ago
    Let's try "Ja'wut". As in "'thentikayshun? Ja, wut am I gonna use for that?"
wvh 10y ago
I guess the general problem with security is that developers use libraries (and frameworks) so as to not have in-depth understanding of the functionality that library provides. That becomes an issue when the library doesn't provide sane defaults or too many options, i.e. ways to shoot yourself in the foot by choosing bad options either by own choice or by programming error – relying on malicious client input. Libraries that provide one solid hard-coded implementation based on current best practices are a much better idea for most projects, but of course what then with giant specs like Oauth and OpenID Connect...
IshKebab 10y ago
> Only if you completely bungle the implementation on the server-side. Did you even read that article? > You could imagine excuses being made about the people who died, or lost their fingers or hands; they were inattentive, they weren't following the right procedure, bad luck happens and we can't do anything about it, etc. "You only die if you completely bungle the coupling."
- dmix 10y ago
  > "You only die if you completely bungle the coupling." That analogy would only really make sense if JWT was always a risk unless the developer set it up properly. But the reality is that the majority of JWT libraries are up to date and don't contain the implementation flaws mentioned. We could tell users to never use a specification because sometimes they might use a library that wasn't implemented right. But there are legit usecases for JWT that the alternatives don't 100% cover and the risks are entirely manageable. So I agree that instead the advice should be "use responsibly", which means use a popular, up-to-date, and well vetted library. All web security authentication options comes with advice like this - just look at OWASP. Unless the state of JWT libraries is terrible, this isn't a big thing to ask. From my experience in two languages (Ruby/Node) there have been high-quality JWT libraries available where the maintainer has stayed on top of known implementation issues with JWT. Eventually JWT libraries in each major language will mature (if they haven't yet already?) and the risks will be quite minimal. The industry (train operators) aren't ignoring the risks here and letting people die... it seems to me that the library authors are adapting.
  - kevinburke 10y ago
    one of the Node libraries has a TODO that says "validate X.509 certificates" the client gets to choose what algorithm they want to use
    - davewritescode 10y ago
      This is so annoying, because one person implements a shitty JWT library the whole spec stupid and should be avoided? Tell that to Amazon, Microsoft, Facebook and and implementer of OpenID Connect. Somehow, they've all figured out use cases where JWT makes sense and it hasn't been a security nightmare. JWT.io has a comprehensive list of not shitty implementations of JWT. It's literally the first page I see when I google JWT.
CiPHPerCoder 10y ago
> Only if you completely bungle the implementation on the server-side. I call this "blaming the user for the designer's error-prone cryptographic designs". The problem with JOSE (the superset of specifications that includes JWT) isn't libraries written by careless developers, the problem with JOSE is the standard itself. 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... If in doubt, ask a cryptographer. The problems, for people who don't want to read articles from comment links, are: - JSON Web Signing - alg headers - "This Header Parameter MUST be present and MUST be understood and processed by implementations." - JSON Web Encryption - RSA with PKCS1v1.5 padding (power word: Bleichenbacher 1998) - ECDH over NIST curves (and, in practice, invalid-curve attacks) - AES-GCM included in a list of asymmetric algorithm choices, for added confusion - AES-GCM for shared-key encryption, without guidance over nonces or key rotation A better solution from JOSE would only give developers two options: - Version (v1, v2, v3, etc. which hard-coded the algorithm choices) - Operation - enc -> crypto_secretbox() - auth -> crypto_auth() - pub-enc -> crypto_box_seal() - pub-sign -> crypto_sign_detached()
- rattray 10y ago
  So, as suggested above, come up with a standard that encodes that subset – "Iron-JWT" or what have you. Much easier for adoption to use a "better version" of the widely-used tool you're already using than some newfangled thing that a guy on HN said was more secure.
  - CiPHPerCoder 10y ago
    I've previously made my proposal to the JOSE IETF mailing list. The participants just held their nose up to it. https://www.ietf.org/mail-archive/web/jose/current/msg05621.html https://www.ietf.org/mail-archive/web/jose/current/msg05621.... https://gist.github.com/paragonie-scott/c88290347c2589b0cd38d8bb6ac27c03 https://gist.github.com/paragonie-scott/c88290347c2589b0cd38... When I'm not dealing with client work, I'll write a replacement for JOSE that has the properties I outlined above. Until I find the free time for this, things that increase my income take precedence.

gant 10y ago

OP literally just deleted a bunch of files from the repo and then went out of his way to break compatibility with normal JWT HS256 tokens by changing the typ and removing the alg argument. If you wanted to pull out other algos from jwt-go, deleting their implementations would've been entirely sufficient. There is a map that holds a alg-string to implementation that would've ended up with only HS256. Instead OP made sure these tokens can't be used outside their fork, and thus only in Go. ISHYGDDT.

skrebbel 10y ago
> ISHYGDDT For readers like me, this means "I seriously hope you guys don't do this."
- gant 10y ago
  Working as intended.
- badosu 10y ago
  Thanks for the information, I find that these acronyms may increase the bandwidth of communication, but the worse quality of the prose and dependence of context that is not always obvious makes this pattern very annoying. I've read this one specifically many times without knowing what it means, whereas the author may think that an interested reader would look up it's meaning, in my case I rejected what I read and moved on.
  - zyx321 10y ago
    ISHYGDDT is 4chan slang. It's deliberately obtuse. You're not supposed to look it up, you're supposed to LURK MORE until you figure it out from context. Even if you do know what it stands for, that's still only half of the true meaning. EDIT: By which I mean this sort of language is not a good fit for an audience that doesn't follow 4chan memes.
    - always_good 10y ago
      Yeah, let's please keep this childish nonsense off of HN. > Even if you do know what it stands for, that's > still only half of the true meaning. I cringed.
      - zyx321 10y ago
        >I cringed. Thank you for your valuable contribution.

JimDabell 10y ago

> Only if you completely bungle the implementation on the server-side. Which happens with regularity. This is exactly what led to the vulnerabilities mentioned in the article. This is a bit like arguing against the claim that generating SQL queries by concatenating strings is unsafe. "Only if you completely bungle escaping the parameters", right? As it turns out, that's an extremely common mistake. It's easier to use a known-safe practice like parameterised queries than it is to rely on developers avoiding this pitfall each and every time they have to execute an SQL query. Likewise with this. We know that negotiating the algorithm is subject to mistakes, and it offers no benefits. So instead of relying on developers avoiding this pitfall each time, let's avoid the pitfall altogether and get rid of negotiation. There's a human aspect to security that's being missed here. Saying what boils down to "well developers shouldn't write insecure code" doesn't actually stop developers from writing insecure code. You can point the finger after the fact, but if you want to actually improve security, we need better standards than this.

Freak_NL 10y ago
> This is a bit like arguing against the claim that generating SQL queries by concatenating strings is unsafe. "Only if you completely bungle escaping the parameters", right? No, you document how it should be done. Any major database layer using SQL provides parametrised SQL queries, and strongly suggests developers use that (usually in the quick start guide). You can still do your own concatenation, but aren't advised to. The JWT libraries that are up-to-date and well-documented don't recommend blindly trusting the algorithm set in the header either, they recommend safe approaches such as configuring your whitelist and letting any unlisted algorithms fail. For example: https://github.com/auth0/java-jwt#verify-a-token https://github.com/auth0/java-jwt#verify-a-token Only if you completely refuse to read even the basic 'getting started' documentation will you get to this kind of weird vulnerability. The issues with this part of the JWT standard have been addressed by the libraries, what remains is just a little bit of effort on the part of the developer — which may be expected from someone writing security critical code. That is, don't blame the hammer for the shoddy carpentry. > So instead of relying on developers avoiding this pitfall each time, let's avoid the pitfall altogether and get rid of negotiation. So write a concise pamphlet that can easily be shared with all of the JWT libraries in an issue/bug report. If there is a good argument for having to explicitly whitelist algorithms, they might welcome the suggestion. Some libraries already do this mind!

eriknstr 10y ago

>JSON Web Token Thanks, I didn't know what JWT meant. When I first read the title I thought it would be about the Google Web Toolkit (GWT) which I incorrectly remembered as being named Java Web Toolkit (JWT) because with GWT you use Java. Author would do well to edit their post, changing the title to "Things to Use Instead of JSON Web Tokens" and replacing the first occurrence of "JWT" in the body text with "JSON Web Tokens (JWT)". In addition to helping visitors from HN, this change could also improve the possibility for others to find the text in the future when they search for JSON Web Tokens using a search engine.

mmmpop 10y ago
To make it more fun, people say JWT as "jot" which sends me into a blind rage.
- Freak_NL 10y ago
  I can imagine. Unfortunately, "jot" is the formal pronunciation of JWT… Makes me glad me and my colleagues are Dutch; we just pronounce the names of the three letters in Dutch — yaywaytay.
  - mmmpop 10y ago
    I prefer that pronunciation too!
- devrandomguy 10y ago
  Let's try "Ja'wut". As in "'thentikayshun? Ja, wut am I gonna use for that?"

wvh 10y ago

I guess the general problem with security is that developers use libraries (and frameworks) so as to not have in-depth understanding of the functionality that library provides. That becomes an issue when the library doesn't provide sane defaults or too many options, i.e. ways to shoot yourself in the foot by choosing bad options either by own choice or by programming error – relying on malicious client input. Libraries that provide one solid hard-coded implementation based on current best practices are a much better idea for most projects, but of course what then with giant specs like Oauth and OpenID Connect...

IshKebab 10y ago

> Only if you completely bungle the implementation on the server-side. Did you even read that article? > You could imagine excuses being made about the people who died, or lost their fingers or hands; they were inattentive, they weren't following the right procedure, bad luck happens and we can't do anything about it, etc. "You only die if you completely bungle the coupling."

dmix 10y ago
> "You only die if you completely bungle the coupling." That analogy would only really make sense if JWT was always a risk unless the developer set it up properly. But the reality is that the majority of JWT libraries are up to date and don't contain the implementation flaws mentioned. We could tell users to never use a specification because sometimes they might use a library that wasn't implemented right. But there are legit usecases for JWT that the alternatives don't 100% cover and the risks are entirely manageable. So I agree that instead the advice should be "use responsibly", which means use a popular, up-to-date, and well vetted library. All web security authentication options comes with advice like this - just look at OWASP. Unless the state of JWT libraries is terrible, this isn't a big thing to ask. From my experience in two languages (Ruby/Node) there have been high-quality JWT libraries available where the maintainer has stayed on top of known implementation issues with JWT. Eventually JWT libraries in each major language will mature (if they haven't yet already?) and the risks will be quite minimal. The industry (train operators) aren't ignoring the risks here and letting people die... it seems to me that the library authors are adapting.
- kevinburke 10y ago
  one of the Node libraries has a TODO that says "validate X.509 certificates" the client gets to choose what algorithm they want to use
  - davewritescode 10y ago
    This is so annoying, because one person implements a shitty JWT library the whole spec stupid and should be avoided? Tell that to Amazon, Microsoft, Facebook and and implementer of OpenID Connect. Somehow, they've all figured out use cases where JWT makes sense and it hasn't been a security nightmare. JWT.io has a comprehensive list of not shitty implementations of JWT. It's literally the first page I see when I google JWT.

CiPHPerCoder 10y ago

> Only if you completely bungle the implementation on the server-side. I call this "blaming the user for the designer's error-prone cryptographic designs". The problem with JOSE (the superset of specifications that includes JWT) isn't libraries written by careless developers, the problem with JOSE is the standard itself. 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... If in doubt, ask a cryptographer. The problems, for people who don't want to read articles from comment links, are: - JSON Web Signing - alg headers - "This Header Parameter MUST be present and MUST be understood and processed by implementations." - JSON Web Encryption - RSA with PKCS1v1.5 padding (power word: Bleichenbacher 1998) - ECDH over NIST curves (and, in practice, invalid-curve attacks) - AES-GCM included in a list of asymmetric algorithm choices, for added confusion - AES-GCM for shared-key encryption, without guidance over nonces or key rotation A better solution from JOSE would only give developers two options: - Version (v1, v2, v3, etc. which hard-coded the algorithm choices) - Operation - enc -> crypto_secretbox() - auth -> crypto_auth() - pub-enc -> crypto_box_seal() - pub-sign -> crypto_sign_detached()

rattray 10y ago
So, as suggested above, come up with a standard that encodes that subset – "Iron-JWT" or what have you. Much easier for adoption to use a "better version" of the widely-used tool you're already using than some newfangled thing that a guy on HN said was more secure.
- CiPHPerCoder 10y ago
  I've previously made my proposal to the JOSE IETF mailing list. The participants just held their nose up to it. https://www.ietf.org/mail-archive/web/jose/current/msg05621.html https://www.ietf.org/mail-archive/web/jose/current/msg05621.... https://gist.github.com/paragonie-scott/c88290347c2589b0cd38d8bb6ac27c03 https://gist.github.com/paragonie-scott/c88290347c2589b0cd38... When I'm not dealing with client work, I'll write a replacement for JOSE that has the properties I outlined above. Until I find the free time for this, things that increase my income take precedence.