4 ms·

An authentication protocol that has this many footguns and insecure defaults is probably just not a very good authentication protocol.

by danjac 6y ago

polymeris 6y ago
That's the thing, JWT is not an authentication protocol, that's just one (the most frequent) use-case of "transfering claims". The footguns, e.g. the choice of encrypted or not, or symmetric or asymmetric crypto, are a result of the flexbility required to cover the other use-cases. Maybe what's needed is a subset of JWT that's just for AuthN.
VzQDfUbMbhuJJT7 6y ago
What would you suggest instead?
user5994461 6y ago
Irrelevant. If the application doesn't call the function to verify the user token, the application is insecure, it doesn't matter what protocol or token format is used.
- rileymat2 6y ago
  To play devils advocate say the design by the library was that you could not read the jwt data without the library verifying it. That goes away.
- andybak 6y ago
  You ignore the fact that some protocols are easier to "do wrong" than others. The point other people are making is that JWT is one of those. You're welcome to disagree but don't gloss over the fundamental point being made.
  - deleted 6y ago
    [deleted]
- chriswarbo 6y ago
  My response to that would be "Parse, don't validate" ( https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va... ). In other words "the function to verify the user token" should also return the payload data (e.g. the user ID, or whatever), and it should ideally be the only way to get that payload data. That way there's very little that can go wrong: - If the verification function doesn't get called, then the application doesn't get its payload data (e.g. user ID), and hence can't be misusing that data. - If the application is using the payload data, then it must have come from the verification function, and hence has been validated. I'm adding JWTs to a system right now, and forcing this interface by encrypting all of the payloads. The only system with access to the decryption key will refuse to decrypt tokens which aren't signed, valid, non-expired, etc.
  - deleted 6y ago
    [deleted]
mooreds 6y ago
That's similar to saying that CRUD apps are bad because you can have SQL injection (as others have mentioned). Or that username/password is a "not very good authentication protocol" because some folks store passwords in a database in plaintext. Sure, the "none" algorithm is a footgun, but just make sure you don't allow it. Maybe I'm talking my book (because I work for a company that sells software which generates JWTs) but I think it isn't that hard to securely validate them. It's just matching on JSON keys, mostly, and can be wrapped up in a library (like https://github.com/jwt/ruby-jwt https://github.com/jwt/ruby-jwt). I also wrote an article on how to build secure JWTs: https://fusionauth.io/learn/expert-advice/tokens/building-a-secure-jwt https://fusionauth.io/learn/expert-advice/tokens/building-a-... I guess the question is, where's the balance between the responsibility of the application developer vs the RFC authors? That's an interesting discussion to have, because I bet there is at least one valid use case for every one of the JWT RFC sections. (I've even heard of valid cases for the "none" algo, like if you are very concerned about performance and have other ways of validating your clients, such as mutual TLS certs.) I've never written an RFC/standard, but I bet it isn't an easy task.

An authentication protocol that has this many footguns and insecure defaults is probably just not a very good authentication protocol.

by danjac 6y ago

An authentication protocol that has this many footguns and insecure defaults is probably just not a very good authentication protocol.

polymeris 6y ago

That's the thing, JWT is not an authentication protocol, that's just one (the most frequent) use-case of "transfering claims". The footguns, e.g. the choice of encrypted or not, or symmetric or asymmetric crypto, are a result of the flexbility required to cover the other use-cases. Maybe what's needed is a subset of JWT that's just for AuthN.

VzQDfUbMbhuJJT7 6y ago

What would you suggest instead?

user5994461 6y ago

Irrelevant. If the application doesn't call the function to verify the user token, the application is insecure, it doesn't matter what protocol or token format is used.

rileymat2 6y ago
To play devils advocate say the design by the library was that you could not read the jwt data without the library verifying it. That goes away.
andybak 6y ago
You ignore the fact that some protocols are easier to "do wrong" than others. The point other people are making is that JWT is one of those. You're welcome to disagree but don't gloss over the fundamental point being made.
- deleted 6y ago
  [deleted]
chriswarbo 6y ago
My response to that would be "Parse, don't validate" ( https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va... ). In other words "the function to verify the user token" should also return the payload data (e.g. the user ID, or whatever), and it should ideally be the only way to get that payload data. That way there's very little that can go wrong: - If the verification function doesn't get called, then the application doesn't get its payload data (e.g. user ID), and hence can't be misusing that data. - If the application is using the payload data, then it must have come from the verification function, and hence has been validated. I'm adding JWTs to a system right now, and forcing this interface by encrypting all of the payloads. The only system with access to the decryption key will refuse to decrypt tokens which aren't signed, valid, non-expired, etc.
- deleted 6y ago
  [deleted]

mooreds 6y ago

That's similar to saying that CRUD apps are bad because you can have SQL injection (as others have mentioned). Or that username/password is a "not very good authentication protocol" because some folks store passwords in a database in plaintext. Sure, the "none" algorithm is a footgun, but just make sure you don't allow it. Maybe I'm talking my book (because I work for a company that sells software which generates JWTs) but I think it isn't that hard to securely validate them. It's just matching on JSON keys, mostly, and can be wrapped up in a library (like https://github.com/jwt/ruby-jwt https://github.com/jwt/ruby-jwt). I also wrote an article on how to build secure JWTs: https://fusionauth.io/learn/expert-advice/tokens/building-a-secure-jwt https://fusionauth.io/learn/expert-advice/tokens/building-a-... I guess the question is, where's the balance between the responsibility of the application developer vs the RFC authors? That's an interesting discussion to have, because I bet there is at least one valid use case for every one of the JWT RFC sections. (I've even heard of valid cases for the "none" algo, like if you are very concerned about performance and have other ways of validating your clients, such as mutual TLS certs.) I've never written an RFC/standard, but I bet it isn't an easy task.