3 ms·

> these are sensitive in of themselves, as they have implementation details for our services, and as mentioned, certain things could be used outside of Capital

by ljm 6y ago

> these are sensitive in of themselves, as they have implementation details for our services, and as mentioned, certain things could be used outside of Capital One. I imagine these JWTs will find their way into a frontend application in prod (because what else would they be for?), at which point any actual user of theirs could pull the token down and get access to these implementation details. The only thing sensitive about a JWT should be its ability to authenticate a user; encoding actually sensitive data inside that token, such as anything you want kept secret, would be a huge mistake.

notimetorelax 6y ago
There are server side JWTs that are never exposed to the users.
- qppo 6y ago
  I thought the entire point of signing a JWT was because you need to validate it because there is some endpoint that is untrusted and you have to treat the claims as potentially compromised.
  - dathinab 6y ago
    JWTs are in end like passwords. Sure they have a limited duration. Sure they might not work for all actions. Sure they don't need a password database on the side of the receiver. But it's best to treat them like temporary password + some arbitrary metadata. So no, they don't protect you from corrupted clients, they just limit the damage in what can happen and when it can happen but the corrupt client can still do all kinds of bad things. Edit: I need a different Android keyboard, this is driving me nuts.
  - lostcolony 6y ago
    Yes? And? I may have a backend service that is both internally and externally exposed, necessitating all requests to it be signed. I may have a backend service that has load limits that need to be fairly adhered to, and to do that I allow users only so many requests per time period. Even without load limits, I may want to know who is calling me, and forcing services to first request a token on behalf of themselves makes it more likely that each service will uniquely identify itself. Really, if you trust the callers of your API enough to allow unsigned JWTs, you probably should trust them enough to not require anything (because copy/paste mistakes alone mean the data isn't valid, intention aside). If you can think of a reason why not having any identity information at all is problematic, you should probably force a signed JWT. The extra effort is negligible, it reduces potential risk if the use of the service changes and it starts getting 'untrusted' users, and it helps reduce "oops" mistakes upfront.
spockz 6y ago
It is rather common practice to encrypt the JWT that is presented to the browser which uses it as an opaque value. Pasting a decrypted token on a public site is then definitely a form of information disclosure. Whether it is exploitable or not is a different question.
- Galanwe 6y ago
  I did not know that. What would be the point of encrypting the JWT? Allowing the client to see the claim should not really be a concern.
  - dathinab 6y ago
    You can put claims (and other metadata) in their which you don't want the client to see. Like you might not want to expose how exactly your internal permission system works to the client to make it harder to find places what did to bad configuration your JWT can be (ab)used to do thinks it shouldn't be able to. (I.e making security bugs harder to find from the outside). Or it could expose internal IDs which might have some privacy concerns. Or the internal IDs are not as security random and you might maybe be able to use that in some way to have a very round about kind of Oracle like attack. Or this internal data could be used to make social engineering attacks easier. .... Edit: or you encapsulate another internal only access token in there which the gateway server your website communicates with used to access the resources you are allowed to access and you want to make sure that a attacker who got access to the internal network somehow doesn't has access to any internal tokens without hijacking a service which has such tokens.
dathinab 6y ago
He spoke not just about JWTs , but also thinks like e.g. certificates. He also mentioned data format displaying tools (e.g. inspect msgpack/json) Internal only certificates might very well point out some internal only details by what fields extension they used with which value.

by ljm 6y ago

notimetorelax 6y ago

There are server side JWTs that are never exposed to the users.

qppo 6y ago
I thought the entire point of signing a JWT was because you need to validate it because there is some endpoint that is untrusted and you have to treat the claims as potentially compromised.
- dathinab 6y ago
  JWTs are in end like passwords. Sure they have a limited duration. Sure they might not work for all actions. Sure they don't need a password database on the side of the receiver. But it's best to treat them like temporary password + some arbitrary metadata. So no, they don't protect you from corrupted clients, they just limit the damage in what can happen and when it can happen but the corrupt client can still do all kinds of bad things. Edit: I need a different Android keyboard, this is driving me nuts.
- lostcolony 6y ago
  Yes? And? I may have a backend service that is both internally and externally exposed, necessitating all requests to it be signed. I may have a backend service that has load limits that need to be fairly adhered to, and to do that I allow users only so many requests per time period. Even without load limits, I may want to know who is calling me, and forcing services to first request a token on behalf of themselves makes it more likely that each service will uniquely identify itself. Really, if you trust the callers of your API enough to allow unsigned JWTs, you probably should trust them enough to not require anything (because copy/paste mistakes alone mean the data isn't valid, intention aside). If you can think of a reason why not having any identity information at all is problematic, you should probably force a signed JWT. The extra effort is negligible, it reduces potential risk if the use of the service changes and it starts getting 'untrusted' users, and it helps reduce "oops" mistakes upfront.

spockz 6y ago

It is rather common practice to encrypt the JWT that is presented to the browser which uses it as an opaque value. Pasting a decrypted token on a public site is then definitely a form of information disclosure. Whether it is exploitable or not is a different question.

Galanwe 6y ago
I did not know that. What would be the point of encrypting the JWT? Allowing the client to see the claim should not really be a concern.
- dathinab 6y ago
  You can put claims (and other metadata) in their which you don't want the client to see. Like you might not want to expose how exactly your internal permission system works to the client to make it harder to find places what did to bad configuration your JWT can be (ab)used to do thinks it shouldn't be able to. (I.e making security bugs harder to find from the outside). Or it could expose internal IDs which might have some privacy concerns. Or the internal IDs are not as security random and you might maybe be able to use that in some way to have a very round about kind of Oracle like attack. Or this internal data could be used to make social engineering attacks easier. .... Edit: or you encapsulate another internal only access token in there which the gateway server your website communicates with used to access the resources you are allowed to access and you want to make sure that a attacker who got access to the internal network somehow doesn't has access to any internal tokens without hijacking a service which has such tokens.

dathinab 6y ago

He spoke not just about JWTs , but also thinks like e.g. certificates. He also mentioned data format displaying tools (e.g. inspect msgpack/json) Internal only certificates might very well point out some internal only details by what fields extension they used with which value.