Secondary Screening: How much is necessary?

[Skyb0rg007]

Currently Anubis randomly (roughly 1 out of every 10 requests) performs a "full validation" of the JWT.
On every request the JWT is validated and verified: the token is properly formatted, was signed by Anubis, and is not expired. For some of the requests additional checks are performed, namely that the "challenge" matches the user-agent, language headers, IP address, etc., and that the "nonce", and "response" fields are a solution to the challenge. This additional check is to prevent a single client from solving the challenge and re-requesting the same page for different languages or sharing the challenge with different IPs.

In my mind the "nonce" and "response" fields of the JWT are not required for verification. As long as Anubis is the only server that signs the tokens, this check was already done at creation (signing) time. So it seems like the only required check is of the "challenge" field, which is just a string comparison.

Perhaps my understanding of the JWT mechanisms is not correct though, so any information on this would be great!

[Xe]

Here's a way to think about it: challenge is mostly provided by the user. Most of the inputs are from requests combined with the public ED25519 signing key to top it off. challenge + nonce + work = response. You can also validate the response based on the nonce and challenge. The wasm PR's sha256 proof of concept may be a good example of the logic ay play.

The info being stored is mostly copied from Hashcash. Notably, it stores the difficulty, time, challenge, and nonce. If anything in my solution storing the response is probably overkill, but I don't quite think we're at the level of shaving bytes yet. If that becomes a problem I can change this to store the hash values in base 64 instead of base 16.

I'm probably about to have to add the algorithm field to signed tokens.

[Skyb0rg007]

challenge + nonce + work = response

Isn’t "nonce" provided by the client as proof-of-work? Ie it’s challenge + work = nonce; challenge + nonce = response; the client gets the challenge and produces the nonce, and the response can be calculated from those two values so there isn’t a reason to transmit it.

You can also validate the response based on the nonce and challenge.

I’m still not sure why you need to check the nonce if you assume that the JWT is properly signed. Anubis is only handing out signed JWTs for challenges that work, no?

I'm probably about to have to add the algorithm field to signed tokens.

I guess my overarching question is why Anubis ever re-checks the PoW to begin with. If the JWT was just "iss","exp","challenge" you have exactly the same security since the fact that the check was done at one point or another is attested by the signing itself (if someone cracks/leaks the private signing key it’s over anyways).