4 ms·

JWTs let you reject unauthorized requests on their face, without having to even make a database call. Protecting your database from even being queried when the

JWTs let you reject unauthorized requests on their face, without having to even make a database call. Protecting your database from even being queried when the request is unauthorized reduces your attack surface enormously.

marcus_holmes 3y ago
I don't get why that's a reduction in attack surface? I guess DDOS attacks - if we're checking the session ID on every request then that's a potential attack if you just make up uuids and throw them at the server. But JWT's themselves are an attack vector, surely? If there's any mistake in the encryption (or any vulnerability in the libraries used) then this is a door open very wide indeed. The beauty of session IDs is the simplicity of it - very few moving parts, so very few opportunities for mischief. JWTs seem to be the opposite: lots of moving parts, lots of opportunities.
- antran22 3y ago
  JWT doesn't encrypt (by default) the payload. The header & payload is passed through base64 and appended with a hash to produce a JWT. JWT verifying doesn't require making API call, and is essentially a hash check. Any verifier with a public verification key can determine if the JWT is bogus by a quick hash check and reject the request right away. Comparing to session IDs, you have no way to know if an unique id is bogus or not. You have to check from a list, be it a cache or a database. This limits the scalability of the solution. I'm not an expert, but AFAIK JWT verifier can be stationed on the edge of the application network, and I have not checked this but I suspect they can even make a hardware solution for those kind of activity. That's definitely a big reduction of attack surface in terms of DDOS. IMO JWT doesn't have that many moving parts. Encryption parameters are handled by libraries according to tested standards. The only real thing you need to do is to keep your private key safe.
  - GTP 3y ago
    > Any verifier with a public verification key can determine if the JWT is bogus So you have to check a signature, right? Maybe this is what the other commenter meant when mentioned encryption.
    - marcus_holmes 3y ago
      Yeah. The mechanics of JWTs are complex, involving maths that is easy to get wrong. Hopefully the implementation is based on a standard library and the author didn't roll their own crypto. Hopefully the library hasn't got any known vulnerabilities. Hopefully the implementation hasn't got any problems. Because the JWT actually contains sensitive information that is useful to an attacker, and if they can forge their own JWTs then the system is wide open; all the attacker needs to do is work out the username of an admin (or worse, the JWT itself tells the system if the user is an admin). Session IDs don't have any of these problems. It does mean you have to do a database lookup on every request, and that can cause problems with scale, but if you have to hit the database anyway for other reasons then you have that problem anyway and have to solve it for those other reasons.
bzbz 3y ago
So sign your UUIDs and combine them into “$UUID:$HASH” strings for the same benefit. Or a more structured JWT-like payload that still verifies auth against the DB (as opposed to carrying authorization within the token). No need to reinvision the rest of the auth flow if you just want to add hashing to reduce DB load.
- cchance 3y ago
  so ... recreate jwt?
unscaled 3y ago
If you're worried about DDoS (and also timing attacks, if you've got a B-Tree index), you can just append an HMAC to your random session ID. I've even seen a few cases of Stateful JWTs, where the JWT contained a session ID and everything else was in the DB. Of course, this approach manages to be both an overkill and a security and inferior to the just-use-an-HMAC approach at the same time.
tptacek 3y ago
So does every Rails and Django encrypted session token.
- jameshart 3y ago
  Sure. Just pushing back on the ‘you’re going to hit the database anyway’ argument. Having some kind of mechanism for eliminating obviously bogus requests is a good idea. Some sort of signed, expiring token is probably a good idea for that. Rolling your own expiry/signing mechanism is probably a bad idea. Correctly validated JWTs are an option (among many) for solving that problem.
- gkbrk 3y ago
  How do you revoke an encrypted session token that doesn't need to hit the database to see if the request is authorized?
  - DecoPerson 3y ago
    Include an expiry time in the encrypted part. The encryption, and the fact the token decrypts invalidly if not encrypted with the correct key, acts like a discount JWT. Encrypted session tokens with embedded expiry will serve the needs of 99% of applications/services.
    - NovemberWhiskey 3y ago
      Revocation in this context almost always means "suspension of the validity of a token prior to expiration", so that's not really an answer.
    - tonyhb 3y ago
      In that case why not use JWTs which do this for you? In your case you end up building a subset of JWTs yourself.
      - the_gipsy 3y ago
        These might predate JWTs.

marcus_holmes 3y ago

I don't get why that's a reduction in attack surface? I guess DDOS attacks - if we're checking the session ID on every request then that's a potential attack if you just make up uuids and throw them at the server. But JWT's themselves are an attack vector, surely? If there's any mistake in the encryption (or any vulnerability in the libraries used) then this is a door open very wide indeed. The beauty of session IDs is the simplicity of it - very few moving parts, so very few opportunities for mischief. JWTs seem to be the opposite: lots of moving parts, lots of opportunities.

antran22 3y ago
JWT doesn't encrypt (by default) the payload. The header & payload is passed through base64 and appended with a hash to produce a JWT. JWT verifying doesn't require making API call, and is essentially a hash check. Any verifier with a public verification key can determine if the JWT is bogus by a quick hash check and reject the request right away. Comparing to session IDs, you have no way to know if an unique id is bogus or not. You have to check from a list, be it a cache or a database. This limits the scalability of the solution. I'm not an expert, but AFAIK JWT verifier can be stationed on the edge of the application network, and I have not checked this but I suspect they can even make a hardware solution for those kind of activity. That's definitely a big reduction of attack surface in terms of DDOS. IMO JWT doesn't have that many moving parts. Encryption parameters are handled by libraries according to tested standards. The only real thing you need to do is to keep your private key safe.
- GTP 3y ago
  > Any verifier with a public verification key can determine if the JWT is bogus So you have to check a signature, right? Maybe this is what the other commenter meant when mentioned encryption.
  - marcus_holmes 3y ago
    Yeah. The mechanics of JWTs are complex, involving maths that is easy to get wrong. Hopefully the implementation is based on a standard library and the author didn't roll their own crypto. Hopefully the library hasn't got any known vulnerabilities. Hopefully the implementation hasn't got any problems. Because the JWT actually contains sensitive information that is useful to an attacker, and if they can forge their own JWTs then the system is wide open; all the attacker needs to do is work out the username of an admin (or worse, the JWT itself tells the system if the user is an admin). Session IDs don't have any of these problems. It does mean you have to do a database lookup on every request, and that can cause problems with scale, but if you have to hit the database anyway for other reasons then you have that problem anyway and have to solve it for those other reasons.

bzbz 3y ago

So sign your UUIDs and combine them into “$UUID:$HASH” strings for the same benefit. Or a more structured JWT-like payload that still verifies auth against the DB (as opposed to carrying authorization within the token). No need to reinvision the rest of the auth flow if you just want to add hashing to reduce DB load.

cchance 3y ago
so ... recreate jwt?

unscaled 3y ago

If you're worried about DDoS (and also timing attacks, if you've got a B-Tree index), you can just append an HMAC to your random session ID. I've even seen a few cases of Stateful JWTs, where the JWT contained a session ID and everything else was in the DB. Of course, this approach manages to be both an overkill and a security and inferior to the just-use-an-HMAC approach at the same time.

tptacek 3y ago

So does every Rails and Django encrypted session token.

jameshart 3y ago
Sure. Just pushing back on the ‘you’re going to hit the database anyway’ argument. Having some kind of mechanism for eliminating obviously bogus requests is a good idea. Some sort of signed, expiring token is probably a good idea for that. Rolling your own expiry/signing mechanism is probably a bad idea. Correctly validated JWTs are an option (among many) for solving that problem.
gkbrk 3y ago
How do you revoke an encrypted session token that doesn't need to hit the database to see if the request is authorized?
- DecoPerson 3y ago
  Include an expiry time in the encrypted part. The encryption, and the fact the token decrypts invalidly if not encrypted with the correct key, acts like a discount JWT. Encrypted session tokens with embedded expiry will serve the needs of 99% of applications/services.
  - NovemberWhiskey 3y ago
    Revocation in this context almost always means "suspension of the validity of a token prior to expiration", so that's not really an answer.
  - tonyhb 3y ago
    In that case why not use JWTs which do this for you? In your case you end up building a subset of JWTs yourself.
    - the_gipsy 3y ago
      These might predate JWTs.