By the way, claps for Tim for the amazing job. He contacted various people and gave them heads up weeks ago. I think the wat this was handled was awesome.
<3 OSS
Critical Vulnerabilities in JSON Web Token Libraries
11–20 of 55 posts
Re: Critical Vulnerabilities in JSON Web Token Libraries
#12Can someone please explain to me the appeal of tokens like the following please?
payload = '{"loggedInAs":"admin","iat":1422779638}'
Is anyone able to expand on this for me please?
Re: Critical Vulnerabilities in JSON Web Token Libraries
#13Can someone please explain to me the appeal of tokens like the following please? payload = '{"loggedInAs":"admin","iat":1422779638}' I've always worked under the assumption that everything the client sends is wrong; which means the only fields I issue are a user hash and session key. If either of those don't match the session table record then the token is rejected. Having group permissions issued from the client sid…
Such a token doesn't require you to have a database to lookup and maintain the user session/permissions in, which can lead to more reliable and lower latency designs.
Re: Critical Vulnerabilities in JSON Web Token Libraries
#14Be wary if you do anything with signed data before you verify the signature. http://www.thoughtcrime.org/blog/the-cryptographic-doom-prin...
That's a great link (which I've seen before) and I upvoted it. But these "typical JWT lib api vulns" are WAY SIMPLER than Vaudenay etc. Any programmer could do this in minutes or less. WOW. It's so obvious and straightforward (in hindsight I suppose). My mouth is still hanging open.
We've recently been looking at adding JWT, and one of the things I looked out for was that we were protected against downgrade attacks. This was done both as a check of the current library code, and an explicit check on our side that the alg is what we expect to protect against future library changes.
Re: Critical Vulnerabilities in JSON Web Token Libraries
#15I don't understand why you need the alg property at all. I mean, you are the one issuing the token so you definitely know what algorithm is used in the back-end. Why is this necessary?
Re: Critical Vulnerabilities in JSON Web Token Libraries
#16Can someone please explain to me the appeal of tokens like the following please? payload = '{"loggedInAs":"admin","iat":1422779638}' I've always worked under the assumption that everything the client sends is wrong; which means the only fields I issue are a user hash and session key. If either of those don't match the session table record then the token is rejected. Having group permissions issued from the client sid…
I agree with you (I do the same).
However, in certain cases it's useful to have stateless sessions (or rather, moving the state to the client, using signed and/or encrypted tokens).
In this case, JWT is used by e.g. OpenID-Connect, to pass data between systems. In some of these use-cases the client is an intermediary, passing along the token.
Re: Critical Vulnerabilities in JSON Web Token Libraries
#17Can someone please explain to me the appeal of tokens like the following please? payload = '{"loggedInAs":"admin","iat":1422779638}' I've always worked under the assumption that everything the client sends is wrong; which means the only fields I issue are a user hash and session key. If either of those don't match the session table record then the token is rejected. Having group permissions issued from the client sid…
Such a token doesn't require you to have a database to lookup and maintain the user session/permissions in, which can lead to more reliable and lower latency designs.
Your "reliability" point I'd question because a session table method is harder to attack. But I'd be willing to agree that their reliability would be on a par with each other (where session tables are weaker, JWT's excel; and visa versa).
If you don't mind me asking a few more questions, how are the JSON web tokens typically authenticated if not via a database? Or are they assumed correct?
edit:
It's becoming impossible to navigate around the complex neuroticisms of every HN member (since it can take only 1 vote to make a comment grey) so a little assistance would be greatly appreciated. :)
Re: Critical Vulnerabilities in JSON Web Token Libraries
#18Can someone please explain to me the appeal of tokens like the following please? payload = '{"loggedInAs":"admin","iat":1422779638}' I've always worked under the assumption that everything the client sends is wrong; which means the only fields I issue are a user hash and session key. If either of those don't match the session table record then the token is rejected. Having group permissions issued from the client sid…
I agree with you (I do the same). However, in certain cases it's useful to have stateless sessions (or rather, moving the state to the client, using signed and/or encrypted tokens). In this case, JWT is used by e.g. OpenID-Connect, to pass data between systems. In some of these use-cases the client is an intermediary, passing along the token.
Like a portable passport rather than a centralised authentication model. That does sound an interesting concept :)
Re: Critical Vulnerabilities in JSON Web Token Libraries
#19Earlier quoted context omitted.
Such a token doesn't require you to have a database to lookup and maintain the user session/permissions in, which can lead to more reliable and lower latency designs.
Your "reliability" point I'd question because a session table method is harder to attack. But I'd be willing to agree that their reliability would be on a par with each other (where session tables are weaker, JWT's excel; and visa versa). If you don't mind me asking a few more questions, how are the JSON web tokens typically authenticated if not via a database? Or are they assumed correct? edit: Would the guy who dow…
That's a security point, not a reliability point. They will be more reliable, as you don't need to talk to e.g. MySQL that might be down or slow. The disadvantage is that they're difficult to revoke.
Cryptography is used to verify them.
Re: Critical Vulnerabilities in JSON Web Token Libraries
#20Be wary if you do anything with signed data before you verify the signature. http://www.thoughtcrime.org/blog/the-cryptographic-doom-prin...
Don't trust the data before you verified it is indeed the common problem here. You have to be careful with JWK in a similar way: the public key can be specified a as a URL via the x5u parameter, you have to make sure you only trust keys from a whitelisted URL otherwise whoever supplies the token signed with a JWK can just provide their own public key and self-sign it.
This can be problematic and need some leg-work on a developer's side when the URLs to be whitelisted aren't documented. For example Apple use a similar signed blob to allow 3rd parties to verify a Game Center identity, using generateIdentityVerificationSignatureWithCompletionHandler. The data you get back includes the publicKeyUrl, but not which URLs to expect. A naive implementation would just download the public key and run with it. Bad for two reasons: you're now downloading data from an arbitrary location and you are trusting a signature that you verified using untrusted information. In case anyone is interested, the two locations I've seen Apple provide here are https://sandbox.gc.apple.com and https://static.gc.apple.com .