Plus the token stored in the session is not hashed. Which means that if you don’t want to sign the session, you will need to at least hash the token to avoid timing attacks. So we are avoiding some of the work if we know it is going to the session.

Also, when it comes to security, having redundant measures is a good thing. For example, if your session tokens table leaks or someone gets access to it, they still won’t be able to sign in as any user because the token is signed (which is why we either hash or sign all tokens).

This thread is kinda useless without a benchmark. Last decade CPU’s have optimizations for signing (and encrypting+decrypting) so I guess the overhead is way to low to bother. Changes are high you can find other code to optimize which in turn increases req/s by a lot more. When using a database, I am confident there is a config flag that will make more difference

But to answer the question: anything not signed will be tampered with! Even when using a large random identifier, a hacker will try. And without rate limiting (cause it influences req/s) you can be sure they will succeed one day. When the session is signed, most hackers will continue to seek weaker spots (on somebody elses application)

Ps. Once you get hacked, the ‘avarage req/s of this year’ will take a huge blow! Be smart; sign.

Maybe another side helps.

Having the session signed helps with runtime performance. It is faster to check a signature instead of doing first a cash lookup and thereafter, a database lookup.

If we take the threat modeled by owasp for getting access to a generic account, an attacker who is doing a brute force attack which we can defend with using a long session token. Each request would hit the database, which is calling a tcp connection. It also does load to your database. And only after that you can block the request.

On the other hand, the signing is just a hmac. This is using sha2 which newer processor have hardware routines backed into. So, the cost is negligible. Hammering this endpoint will not result in a risk of overusing your database. I would not say, that this prevents the need of using a request limiter. You still want to implement something like this.

This does not prevent the access of a middler in the middle attack.

The other threat josevalim mentioned, an attacket that gained access to your data.

Without signing you have a problem because now you have to trust that your sessions a short living. But the default for the session is 60 days. So enough time for an attacker to do some nasty stuff. Signing prevents this. And the statistics say you should not ask if your database leaks, but rather when your database leaks. So assuming that your data from the database will be public sometime in the feature is a good measurement. Because of this, you should also encrypt all personal stuff in your database.

I hope this shade some light on why signing is a good idea.