I have written a trivial custom session handler (in MySQL, but that’s not relevant) which simply saves serialized session data, the session id, and the current time to a table.
While the session exists, the session id is as valuable as a password for an attacker, which leads me to believe that I should be encrypting it in some way.
Is it worthwhile to hash the session id before storing it in the database in order to force an attacker to bruteforce the session id to forge a cookie?
My site already uses HTTPS for all connections.
So what you’re trying to prevent is that if an attacker gets access to a dump of session ids from your database, he could pose as any arbitrary user because he can use the session id as is. For this it’s actually a pretty good idea to hash the id the same way you’d hash a password, so one-way lookups are possible, but the hashed value itself has become useless. Since session ids also expire quite quickly usually, there’s little use in brute-forcing.
On the other hand, since session ids expire quite quickly usually, there may not be much point to it to begin with. The window of opportunity is very small for an attacker. The very fact that the attacker was able to get a dump of session ids from your database weighs much heavier and is a much worse breach, since it means the attacker probably already has access to other data as well.
It is still a worthy defense with little downsides (slight computational overhead, slightly more complicated debugging of session ids).