131–140 of 158 posts
Earlier quoted context omitted.
No they don't. JWTs sign the whole token.
They're also notoriously fragile!
I accept there's fragility in the wider distributed-authX/federation ecosystem (e.g. browser cookie policies breaking OIDC), but that's not inherent in JWT.
Earlier quoted context omitted.
This is possible with anything, though. If your verification code trusts the input, that's bad. That's not a structural weakness of the JWT format.
> This is possible with anything, though. If your verification code trusts the input, that's bad. That's not a structural weakness of the JWT format. What's the purpose of the algorithm field in the header if clients shouldn't trust it? It's "input", after all...
Someone specifies the `null` algorithm? Reject the token outright, someone's trying fudge things. Someone specifies the `blahwhatever` algorithm that you actually trust yourself. Sure, try that algorithm, if results come back valid, all is good. Results come back bad? Reject the input without trying any of the other 19 algorithms you support and trust on the input.
As you can see here, the purpose of the field is to make it easy to validate the token without having to try all the algorithms that you might support. If you support 20 algorithms for something, you don't want to have to try all of them. But you do have to know which algorithms you trust. It's really not different from an SSL negotiation. You know which algorithms you accept/support, the other side knows what algorithms it accepts/supports. If you can't find one both of you support: tough luck!
Earlier quoted context omitted.
This is possible with anything, though. If your verification code trusts the input, that's bad. That's not a structural weakness of the JWT format.
> This is possible with anything, though. If your verification code trusts the input, that's bad. That's not a structural weakness of the JWT format. What's the purpose of the algorithm field in the header if clients shouldn't trust it? It's "input", after all...
JWS (and JWT) standardized interoperable parameters and what they mean, but applications are supposed to standardize how they are used.
An integrity protected message used as part of a transaction, one used to represent user state, and one used for document archival are going to have dramatically different requirements for verification metadata.
Similarly, a signed message issued by a single site vs one meant for use across a federation will have different requirements.
This is the #1 misconception of JWS/JWT which has led to people mislabeling it as insecure. They are only using the half that defines what fields mean, and ignoring application-specific instructions on if they are supposed to accept and how they are supposed to process those fields.
Earlier quoted context omitted.
They're also notoriously fragile!
Can you be more specific? a JWT's structure is really simple and easier to process compared to what came before (SAML, etc). I accept there's fragility in the wider distributed-authX/federation ecosystem (e.g. browser cookie policies breaking OIDC), but that's not inherent in JWT.
Signed OOXML Word files are ZIP files defined by what appear to be 3 manifests: a content-types.xml file, a document.rels.xml file that maps symbolic IDs to filenames, and the "Package Info" section of the signature block, which supplies hashes for all signed files. The rendering of an OOXML Word file starts from "document.xml". Here are the attacks, as I understand them: 1. OOXML doesn't sign content-types.xml. It a…
A couple years ago I wanted to link the spec to my resume and found it was not freely available. Now I’d like to see a copy to verify whether in retrospect I missed anything.
Among the decisions I made:
- provide no metadata until the signature has verified.
- implement your own file extraction logic, use the same logic for locating elements and assets
- don’t touch the file system until the signature has verified
- implement metadata functions using the same code used for locating elements
- use prefetch for xml namespaces, disable network requests
- implement a wrapper around getElementByID, throw an error if multiple elements are ever found (including searching from the root element).
- only extract files and elements that were signed
- canonicalize paths
- implement multiple warnings for impending cert expiration
- be very, very careful if you allow multiple signatures
- watch out for one team demanding requirements that prevent their counterparts from operating
- get used to saying, “no”, but offering workaroundsEarlier quoted context omitted.
It doesn't need to be 256 random bits. The chosen design smears the key, so if your password has 10 bits of randomness, my best attack is to try those 10 bits worth of passwords. That is practical to try, but if I have enough bits you might as well just guess keys, which you can't do, so, game over. It does need to be actual randomness, so "NameOfCorp" won't work to protect Corp's documents, but people need to get ov…
> 44 bits of randomness might be feasible for a serious attacker, while maybe if it was 1000 times harder they'd give up My back-of-the-napkin math[^1] says that, on an AMD Ryzen 7 1800X (released in 2017), brute-forcing 54 bits of entropy in AES-256-GCM takes an average of about 2.6 months. That’s on (pretty outdated) consumer hardware, not GPUs, specialized ASICs, or parallelizing across different machines. That’s…
But, Office isn't a client-server setup, it's desktop software. So the encrypted file, and the software, live on somebody's five year old work laptop. They are not running a tuned brute force kernel, they are general purpose software, and so unsurprisingly they'll take much longer than your estimate from a brute force kernel on chosen hardware.
Now you've made Kirsty the assistant secretary moan that opening the encrypted Excel sheet takes "forever". Guess what they do about that? Did you guess they adjust the tuning slightly to ease it off? Nah, that's a Microsoft internals parameter, Kirsty's team just stop using encryption altogether, game over.
The "guideline" you're talking about is reasonable for web sites and similar systems as a poor alternative or adjunct to e.g. WebAuthn, but it doesn't make much sense for systems like Office.
Earlier quoted context omitted.
This is possible with anything, though. If your verification code trusts the input, that's bad. That's not a structural weakness of the JWT format.
> This is possible with anything, though. If your verification code trusts the input, that's bad. That's not a structural weakness of the JWT format. What's the purpose of the algorithm field in the header if clients shouldn't trust it? It's "input", after all...
Earlier quoted context omitted.
> This is possible with anything, though. If your verification code trusts the input, that's bad. That's not a structural weakness of the JWT format. What's the purpose of the algorithm field in the header if clients shouldn't trust it? It's "input", after all...
The point of input in any case is that you are going to validate it and then process it. Any input that isn't validated should not be trusted, even in the most benign scenarios and triply so in security relevant contexts. Someone specifies the `null` algorithm? Reject the token outright, someone's trying fudge things. Someone specifies the `blahwhatever` algorithm that you actually trust yourself. Sure, try that algo…
Had the algorithm been standardised to a single value out of band (ie. in the spec), that would have squashed a whole load of vulnerabilities.
Earlier quoted context omitted.
Can you be more specific? a JWT's structure is really simple and easier to process compared to what came before (SAML, etc). I accept there's fragility in the wider distributed-authX/federation ecosystem (e.g. browser cookie policies breaking OIDC), but that's not inherent in JWT.
https://fly.io/blog/api-tokens-a-tedious-survey/