3 ms·

Would someone comment on this idea in context of JWTs? Not trolling, just curious as I use JWTs and embed this kind of metadata as a custom claim, which accompl

by gkop 6y ago

Would someone comment on this idea in context of JWTs? Not trolling, just curious as I use JWTs and embed this kind of metadata as a custom claim, which accomplishes some but far from all of what GitHub accomplishes here, but then I have no need for the easy scanning. So seeking wisdom from anyone who has thought carefully about whether or not to prefix their JWTs in this way.

paxys 6y ago
A big motivation for such token formats is to quickly and easily identity when they are shared somewhere they shouldn't be. JWTs aren't helpful in that regard, since they always present themselves as a base64 encoded blob.
- gkop 6y ago
  Totally, but JWT-like blobs can be detected (see sibling comment), and parsing attempted, so for the automated scanning use case, if I understand correctly, it can be done with perfect accuracy, just at a larger computation expense and worse security exposure due to the complexity of the scanning and the need to parse. The more interesting side to me is the benefit to humans, from the prefix technique.
- threeseed 6y ago
  The question is why you couldn't just have "${prefix}-${JWT}" as your format. Then you can just strip the prefix before parsing. Which means don't need to worry about checksumming or entropy and you have the ability to embed large amounts of data as well as plenty of client support and libraries. Would be curious if this implementation is somehow more performant.
  - benatkin 6y ago
    Yeah, what GitHub is doing by including the checksum is reinventing JWT, with HS256 precisely. They could also make it easy to grep (see other comment) by having the payload always start with the same prefix - if it starts with `{"gh":"` the jwt will contain `.eyJnaCI6I` The subject doesn't need to be a user ID, and it sounds like they don't want that. It could be a session ID.
- parhamn 6y ago
  It’s pretty grepable because {“ (json opener) always encode to “ey”. So a base64 that starts with “ey” and has 3 dot separated sections is a good start for a regex. I’m sure you can go further by looking at the spec.
  - jameshart 6y ago
    Yep. eyJ<base64stuff>.eyJ<base64stuff>.<base64stuff> is pretty definitely a JWT - if you see it in a log output you should probably redact at least the first and third blocks of base64. But JWTs are generally somewhat ephemeral (they expire) so you’re fairly unlikely to commit one into a source repo in a way that could do actual damage...
    - benatkin 6y ago
      This is great. If you start with the same thing in your payload (with whitespace removed and key ordering preserved), you can add that to what you grep. If GitHub used JWT and started the payload (the second of the three dot separated items) with `{"gh":`, they could grep it like this: eyJ<base64stuff>.eyJnaCI6I<base64stuff>.<base64stuff>
benatkin 6y ago
JWTs purposely contain information in plain text (unencrypted and not stored in a database), however it is in base64 so you don't need to worry about url encoding issues and so it looks like a token. You could add a prefix to a jwt. That would make it a token that contains a jwt. I don't think the tiny prefix is what they want to obscure. So it wouldn't go against the design of JWT to add one. I would do it. I don't see any issues with it. It would be something like: BA_<base64>.<base64>.base64 If you wanted to be able to double click to copy and paste, which I don't think is a huge usability improvement, you could replace the . with _, and I think a lot of devs would be able to figure out that it's a representation of a JWT.

by gkop 6y ago

paxys 6y ago

A big motivation for such token formats is to quickly and easily identity when they are shared somewhere they shouldn't be. JWTs aren't helpful in that regard, since they always present themselves as a base64 encoded blob.

gkop 6y ago
Totally, but JWT-like blobs can be detected (see sibling comment), and parsing attempted, so for the automated scanning use case, if I understand correctly, it can be done with perfect accuracy, just at a larger computation expense and worse security exposure due to the complexity of the scanning and the need to parse. The more interesting side to me is the benefit to humans, from the prefix technique.
threeseed 6y ago
The question is why you couldn't just have "${prefix}-${JWT}" as your format. Then you can just strip the prefix before parsing. Which means don't need to worry about checksumming or entropy and you have the ability to embed large amounts of data as well as plenty of client support and libraries. Would be curious if this implementation is somehow more performant.
- benatkin 6y ago
  Yeah, what GitHub is doing by including the checksum is reinventing JWT, with HS256 precisely. They could also make it easy to grep (see other comment) by having the payload always start with the same prefix - if it starts with `{"gh":"` the jwt will contain `.eyJnaCI6I` The subject doesn't need to be a user ID, and it sounds like they don't want that. It could be a session ID.
parhamn 6y ago
It’s pretty grepable because {“ (json opener) always encode to “ey”. So a base64 that starts with “ey” and has 3 dot separated sections is a good start for a regex. I’m sure you can go further by looking at the spec.
- jameshart 6y ago
  Yep. eyJ<base64stuff>.eyJ<base64stuff>.<base64stuff> is pretty definitely a JWT - if you see it in a log output you should probably redact at least the first and third blocks of base64. But JWTs are generally somewhat ephemeral (they expire) so you’re fairly unlikely to commit one into a source repo in a way that could do actual damage...
  - benatkin 6y ago
    This is great. If you start with the same thing in your payload (with whitespace removed and key ordering preserved), you can add that to what you grep. If GitHub used JWT and started the payload (the second of the three dot separated items) with `{"gh":`, they could grep it like this: eyJ<base64stuff>.eyJnaCI6I<base64stuff>.<base64stuff>

benatkin 6y ago

JWTs purposely contain information in plain text (unencrypted and not stored in a database), however it is in base64 so you don't need to worry about url encoding issues and so it looks like a token. You could add a prefix to a jwt. That would make it a token that contains a jwt. I don't think the tiny prefix is what they want to obscure. So it wouldn't go against the design of JWT to add one. I would do it. I don't see any issues with it. It would be something like: BA_<base64>.<base64>.base64 If you wanted to be able to double click to copy and paste, which I don't think is a huge usability improvement, you could replace the . with _, and I think a lot of devs would be able to figure out that it's a representation of a JWT.