7 ms·

JWTs are useful, but there are a few things that are not immediately obvious. 1) They are signed not encrypted. Anything you put in there is public readable, u

JWTs are useful, but there are a few things that are not immediately obvious. 1) They are signed not encrypted. Anything you put in there is public readable, unless you encrypt your token after you generate it 2) you can accept a range of encryption types, don't. Stick to one type and disallow any token that doesn't conform (this protects against people making their own tokens with 'None' as the signing algorithm) I am surprised at how naive the JWT spec is. Why in this day an age is encryption a default for the _payload_? Also, why on earth is 'None' allowed as a signing algorithm? Thats just a cookie..

manigandham 8y ago
To be clear, cookies are an HTTP header field that can carry any text data you want. You can pass plain text, JWTs or any other encrypted payload (which many web frameworks do automatically). JWTs aren't comparable to cookies, they're just a standard way to sign data.
- pkulak 8y ago
  His or her point was that if you don't sign and/or encrypt, there's no benefit over a standard cookie.
  - techslave 8y ago
    not sure if that was the point or not, but it's wrong. even if you did sign/encrypt, that's not a benefit over a standard cookie. you can easily sign or encrypt a 'standard cookie' as well. the benefit is the portability that comes from a standardized and widely used data structure.
    - kbenson 8y ago
      You say that as if cookies haven't been a standardized and widely used data structure (key-value store) for decades.
      - johncolanduoni 8y ago
        No, they say it as if cookies don’t have a built in authentication or encryption method (when the client is untrusted).
    - KaiserPro 8y ago
      My point was that allowing 'None' was/is a flaw. If you want to shuttle bits of data about in an unsigned/unencrypted/insecure way, that's what raw cookies are for. Now, as cookies are buckets to dump data, there is of course nothing to stop you encrypting, signing and doing all sorts of things to cookies.
ForHackernews 8y ago
You can have unsigned, signed, or encrypted JWTs. You're correct that many JWT libraries only do signed tokens by default, but there's a whole spec devoted to encryption: https://tools.ietf.org/html/rfc7516 https://tools.ietf.org/html/rfc7516 (whether or not your library of choice implements it is a separate question)
- andrewstuart2 8y ago
  This is one of the things I truly appreciate about JWT. They made it a) easy and b) possible to do signing, encryption, or both. If you've ever taken a shot at learning the specs behind SAML, the simplicity of JWT is hugely refreshing.
  - Freak_NL 8y ago
    I wholeheartedly agree. I've had the opportunity to use both implementing a single sign-on solution with an ADFS server, and it is quite interesting to see how OpenID Connect and JWT basically do what SAML and the ADFS SSO authentication flow do; just with a much, much smaller payload and a way more accessible standard. Also, finding information and documentation on JWT and related technologies on-line is a lot easier.
  - nwhatt 8y ago
    Thank you for comparing it to SAML. I feel like anytime JWT is mentioned on HN people jump to discard it as rubbish, but really it's useful for people who actually need to exchange claims.
ros65536 8y ago
As mentioned in the article you might want the token to be read by the users. Such as issuing a token with a expiry date that you want the user to regenerate. Although If anything the JWT libraries should have encryption enabled by default.
- moduspwnens14 8y ago
  It can also be helpful if: - your system is distributed - you don't want to be keeping a decryption key secure and in-sync across many (and potentially less-trusted) nodes - the JWT contains attributes useful to the system (e.g. role, user ID, etc.) You'll probably still be keeping track of a public key of whatever's signing it (to verify authenticity), but that isn't a secret. And then you can still securely trust
  - KaiserPro 8y ago
    > your system is distributed if you don't have a shared data store, or its not fast enough, then you're doing the wrong thing with the wrong tools > you don't want to be keeping a decryption key secure and in-sync across many (and potentially less-trusted) nodes keeping shared secrets, which are very high read:write ratio, and change daily or less, should be childs play. If its not, then your security protocols are wrong. Key rotation must be simple and quick if you want your system to scale. When you get to 100 people, you'll be leaking keys weekly. KMS, Vault and a few others are your friend here. There are off the shelf systems for this. > the JWT contains attributes useful to the system (e.g. role, user ID, etc.) having these public can be alright, assuming that you've properly mapped, scrubbed and checked for leakage. However, you shouldn't be reliant on user supplied stuff for this. You simply cannot trust the user. If you need jwt for caching data, then you have a much bigger architectural problem. The stuff you are storing in JWT needs to be easily and quickly accessed. If its not, you either have a DB or a messaging system issue. Now, if you are encrypting the whole token, then its less of an issue. But, using it to store anything other than a UUID and a issue time, you are asking for trouble.
mattferderer 8y ago
> 1) They are signed not encrypted. Anything you put in there is public readable, unless you encrypt your token after you generate it Not a JWT expert but isn't this the point of a JWT or am I missing something. Sharing data between servers & clients while being able to make sure the data wasn't changed. > 2) you can accept a range of encryption types, don't. Stick to one type and disallow any token that doesn't conform (this protects against people making their own tokens with 'None' as the signing algorithm) People do this?? Why?
- Freak_NL 8y ago
  Libraries did that. Most now guard against this by forcing the developer to explicitly enable the 'None' algorithm. Normally you don't need it, and certainly never in production. But yeah, if your server accepts JWT's, reject anything that doesn't use an algorithm from your whitelist, which usually contains just one entry.
  - tptacek 8y ago
    Most libraries do guard against this. But the point of a "standard" like JOSE/JWT is that you don't have to depend on a library; you should be able to consult the spec and build your own library. And, of course, alg:None is yet another pitfall that JOSE pointlessly opts you in to; it's yet another thing you need to know to safely implement JWT (it's far from the trickiest thing you need to know!)
- smadge 8y ago
  > Sharing data between servers & clients while being able to make sure the data wasn't changed. I think the main use is sharing data between the server and itself. The client shouldn’t depend on the internal structure of the token. The token should just be issued by the server to the client, and the client passes it along to subsequent requests to the server.
  - mattferderer 8y ago
    Both good points!
jka 8y ago
There are also a number of easy-to-make mistakes or gaps which can be introduced with the use of JWTs. https://twitter.com/ejcx_/status/1063846166029197312 https://twitter.com/ejcx_/status/1063846166029197312 provides a great list of test cases covering the commonly reoccurring flaws. The number and seriousness of these errors and how easy it is to make them does raise questions about how sensible it is to use JWT, unless you're really sure about what you're doing.
- andrewstuart2 8y ago
  There are a number of easy-to-make mistakes with all security software. That doesn't mean it's not worth using; it just means that we should build the tooling we need in the open as shared software, so that the wisdom of crowds prevails. Almost exactly the same set of problems exists with signed x509 certificates, but I doubt anybody would tell you not to use them. They'd just say "make sure you don't implement your own validation, unless you absolutely have to, which you don't, and even then only with lots and lots of review/audits." The wisdom with JWT should be the same, IMO.
  - kevinburke 8y ago
    Saying "all security software has flaws" advantages the software with the most flaws and disadvantages the software with the fewest number of flaws. There are many, many better solutions for the problem JWT solves, there are not many better solutions for X509, which is why people keep using X509. It is significantly more difficult to misuse e.g. golang.org/x/crypto/nacl/secretbox than JWT.
    - andrewstuart2 8y ago
      I never said "all security software has flaws," since that has a substantially different meaning than my comment. While I'm not arguing with your statement regarding ease of misuse, you should also consider the trade-offs. It's also significantly easier to misuse a pocket knife than a butter knife for the same reason. Butter knives are designed for a small set of problems and deliberately have duller edges to avoid some of the potential downsides of pocket knives. That doesn't make pocket knives useless, it just means that you might need to be trained on safely using a pocket knife, whereas I'm totally comfortable handing a butter knife to my four-year-old. If you're going to be trusted with security, you're really going to need either a) a sharper knife, or b) to understand which knives you're okay handing to your coworkers, or c) to be able to train your coworkers on proper knife safety so they can also use the more flexible tools, but still safely.
deleted 8y ago
[deleted]
hinkley 8y ago
You aren’t required to be competent to put out a spec. Just join a committee. Did you ever look at the XML digital signature spec? You could drive a freight train through the holes in that one. One guy did an entire conference presentation on the ones he found (took me about a year to find nearly all of the same ones and a few more).
lambdadmitry 8y ago
> unless you encrypt your token after you generate it Generally it's better to avoid unauthenticated encryption. That is, encrypt-than-sign, not the other way around.
deleted 8y ago
[deleted]
paulddraper 8y ago
> Why in this day an age is encryption not a default for the _payload_? Why would it be? Why not encrypt the disk and use SSL? Doing encryption right can be enormously difficult; why not use the transport/storage technologies that are ubiquitous?
- Kalium 8y ago
  You're right. Doing encryption correctly can be incredibly difficult and complex. Enough so that people might miss important subtleties of the technologies at hand. For instance, you may want the encryption of data-in-transit to be removed by the application, rather than by whatever is responsible for TLS termination. You may not want your load balancer to be capable of reading the most sensitive data of your request.
  - paulddraper 8y ago
    IDK what the details are there, but if you trust your TLS termination point with most data, it seems like you'd trust it with the JWT payload too.
    - Kalium 8y ago
      I understand why a person might opt to think in that way! It's an obvious approach when people fully trust every part of their systems. It's perhaps possible some might differ, especially in a context where limiting trust and misuse-resistance are concerns. Giving people the choice of encrypting or signing or both could seen by some as potentially less than maximally misuse-resistant.

manigandham 8y ago

To be clear, cookies are an HTTP header field that can carry any text data you want. You can pass plain text, JWTs or any other encrypted payload (which many web frameworks do automatically). JWTs aren't comparable to cookies, they're just a standard way to sign data.

pkulak 8y ago
His or her point was that if you don't sign and/or encrypt, there's no benefit over a standard cookie.
- techslave 8y ago
  not sure if that was the point or not, but it's wrong. even if you did sign/encrypt, that's not a benefit over a standard cookie. you can easily sign or encrypt a 'standard cookie' as well. the benefit is the portability that comes from a standardized and widely used data structure.
  - kbenson 8y ago
    You say that as if cookies haven't been a standardized and widely used data structure (key-value store) for decades.
    - johncolanduoni 8y ago
      No, they say it as if cookies don’t have a built in authentication or encryption method (when the client is untrusted).
  - KaiserPro 8y ago
    My point was that allowing 'None' was/is a flaw. If you want to shuttle bits of data about in an unsigned/unencrypted/insecure way, that's what raw cookies are for. Now, as cookies are buckets to dump data, there is of course nothing to stop you encrypting, signing and doing all sorts of things to cookies.

ForHackernews 8y ago

You can have unsigned, signed, or encrypted JWTs. You're correct that many JWT libraries only do signed tokens by default, but there's a whole spec devoted to encryption: https://tools.ietf.org/html/rfc7516 https://tools.ietf.org/html/rfc7516 (whether or not your library of choice implements it is a separate question)

andrewstuart2 8y ago
This is one of the things I truly appreciate about JWT. They made it a) easy and b) possible to do signing, encryption, or both. If you've ever taken a shot at learning the specs behind SAML, the simplicity of JWT is hugely refreshing.
- Freak_NL 8y ago
  I wholeheartedly agree. I've had the opportunity to use both implementing a single sign-on solution with an ADFS server, and it is quite interesting to see how OpenID Connect and JWT basically do what SAML and the ADFS SSO authentication flow do; just with a much, much smaller payload and a way more accessible standard. Also, finding information and documentation on JWT and related technologies on-line is a lot easier.
- nwhatt 8y ago
  Thank you for comparing it to SAML. I feel like anytime JWT is mentioned on HN people jump to discard it as rubbish, but really it's useful for people who actually need to exchange claims.

ros65536 8y ago

As mentioned in the article you might want the token to be read by the users. Such as issuing a token with a expiry date that you want the user to regenerate. Although If anything the JWT libraries should have encryption enabled by default.

moduspwnens14 8y ago
It can also be helpful if: - your system is distributed - you don't want to be keeping a decryption key secure and in-sync across many (and potentially less-trusted) nodes - the JWT contains attributes useful to the system (e.g. role, user ID, etc.) You'll probably still be keeping track of a public key of whatever's signing it (to verify authenticity), but that isn't a secret. And then you can still securely trust
- KaiserPro 8y ago
  > your system is distributed if you don't have a shared data store, or its not fast enough, then you're doing the wrong thing with the wrong tools > you don't want to be keeping a decryption key secure and in-sync across many (and potentially less-trusted) nodes keeping shared secrets, which are very high read:write ratio, and change daily or less, should be childs play. If its not, then your security protocols are wrong. Key rotation must be simple and quick if you want your system to scale. When you get to 100 people, you'll be leaking keys weekly. KMS, Vault and a few others are your friend here. There are off the shelf systems for this. > the JWT contains attributes useful to the system (e.g. role, user ID, etc.) having these public can be alright, assuming that you've properly mapped, scrubbed and checked for leakage. However, you shouldn't be reliant on user supplied stuff for this. You simply cannot trust the user. If you need jwt for caching data, then you have a much bigger architectural problem. The stuff you are storing in JWT needs to be easily and quickly accessed. If its not, you either have a DB or a messaging system issue. Now, if you are encrypting the whole token, then its less of an issue. But, using it to store anything other than a UUID and a issue time, you are asking for trouble.

mattferderer 8y ago

> 1) They are signed not encrypted. Anything you put in there is public readable, unless you encrypt your token after you generate it Not a JWT expert but isn't this the point of a JWT or am I missing something. Sharing data between servers & clients while being able to make sure the data wasn't changed. > 2) you can accept a range of encryption types, don't. Stick to one type and disallow any token that doesn't conform (this protects against people making their own tokens with 'None' as the signing algorithm) People do this?? Why?

Freak_NL 8y ago
Libraries did that. Most now guard against this by forcing the developer to explicitly enable the 'None' algorithm. Normally you don't need it, and certainly never in production. But yeah, if your server accepts JWT's, reject anything that doesn't use an algorithm from your whitelist, which usually contains just one entry.
- tptacek 8y ago
  Most libraries do guard against this. But the point of a "standard" like JOSE/JWT is that you don't have to depend on a library; you should be able to consult the spec and build your own library. And, of course, alg:None is yet another pitfall that JOSE pointlessly opts you in to; it's yet another thing you need to know to safely implement JWT (it's far from the trickiest thing you need to know!)
smadge 8y ago
> Sharing data between servers & clients while being able to make sure the data wasn't changed. I think the main use is sharing data between the server and itself. The client shouldn’t depend on the internal structure of the token. The token should just be issued by the server to the client, and the client passes it along to subsequent requests to the server.
- mattferderer 8y ago
  Both good points!

jka 8y ago

There are also a number of easy-to-make mistakes or gaps which can be introduced with the use of JWTs. https://twitter.com/ejcx_/status/1063846166029197312 https://twitter.com/ejcx_/status/1063846166029197312 provides a great list of test cases covering the commonly reoccurring flaws. The number and seriousness of these errors and how easy it is to make them does raise questions about how sensible it is to use JWT, unless you're really sure about what you're doing.

andrewstuart2 8y ago
There are a number of easy-to-make mistakes with all security software. That doesn't mean it's not worth using; it just means that we should build the tooling we need in the open as shared software, so that the wisdom of crowds prevails. Almost exactly the same set of problems exists with signed x509 certificates, but I doubt anybody would tell you not to use them. They'd just say "make sure you don't implement your own validation, unless you absolutely have to, which you don't, and even then only with lots and lots of review/audits." The wisdom with JWT should be the same, IMO.
- kevinburke 8y ago
  Saying "all security software has flaws" advantages the software with the most flaws and disadvantages the software with the fewest number of flaws. There are many, many better solutions for the problem JWT solves, there are not many better solutions for X509, which is why people keep using X509. It is significantly more difficult to misuse e.g. golang.org/x/crypto/nacl/secretbox than JWT.
  - andrewstuart2 8y ago
    I never said "all security software has flaws," since that has a substantially different meaning than my comment. While I'm not arguing with your statement regarding ease of misuse, you should also consider the trade-offs. It's also significantly easier to misuse a pocket knife than a butter knife for the same reason. Butter knives are designed for a small set of problems and deliberately have duller edges to avoid some of the potential downsides of pocket knives. That doesn't make pocket knives useless, it just means that you might need to be trained on safely using a pocket knife, whereas I'm totally comfortable handing a butter knife to my four-year-old. If you're going to be trusted with security, you're really going to need either a) a sharper knife, or b) to understand which knives you're okay handing to your coworkers, or c) to be able to train your coworkers on proper knife safety so they can also use the more flexible tools, but still safely.

deleted 8y ago

[deleted]

hinkley 8y ago

You aren’t required to be competent to put out a spec. Just join a committee. Did you ever look at the XML digital signature spec? You could drive a freight train through the holes in that one. One guy did an entire conference presentation on the ones he found (took me about a year to find nearly all of the same ones and a few more).

lambdadmitry 8y ago

> unless you encrypt your token after you generate it Generally it's better to avoid unauthenticated encryption. That is, encrypt-than-sign, not the other way around.

deleted 8y ago

[deleted]

paulddraper 8y ago

> Why in this day an age is encryption not a default for the _payload_? Why would it be? Why not encrypt the disk and use SSL? Doing encryption right can be enormously difficult; why not use the transport/storage technologies that are ubiquitous?

Kalium 8y ago
You're right. Doing encryption correctly can be incredibly difficult and complex. Enough so that people might miss important subtleties of the technologies at hand. For instance, you may want the encryption of data-in-transit to be removed by the application, rather than by whatever is responsible for TLS termination. You may not want your load balancer to be capable of reading the most sensitive data of your request.
- paulddraper 8y ago
  IDK what the details are there, but if you trust your TLS termination point with most data, it seems like you'd trust it with the JWT payload too.
  - Kalium 8y ago
    I understand why a person might opt to think in that way! It's an obvious approach when people fully trust every part of their systems. It's perhaps possible some might differ, especially in a context where limiting trust and misuse-resistance are concerns. Giving people the choice of encrypting or signing or both could seen by some as potentially less than maximally misuse-resistant.