Securing http session id's by appending HMAC hash?

Question

First, I apologize if this question is off topic as defined here. If so, please let me know and I'll close it.

I'm building a sessions middleware for an http service and thought it might be a good idea to append hmac hashes of session id's, rather then setting bare session id's in cookies, but am a bit of a crypto novice. FYI - the service isn't protecting anything critical, it's just a side project of mine, which is why I'm rolling my own solution.

First, allow me to layout the general sessions design, and I'll follow with some specific questions. Here is an overview of my sessions service:

1. Generate a random session id using an RFC 4122 version 4 uuid generator. I store this id in redis along with some other info (userID, expiry, etc.).
2. Hash the byte array of this session id with hmac sha512. My hashing key was generated with openssl $ openssl rand -base64 64
3. Append the bytes of the hmac hash to the the byte array of the session id. Base64 encode the resulting array, stringify and set as an http only, secure cookie.

Upon receiving a request from a client, verifying the user session is basically the steps above, but in reverse.

My questions are:

1. Does appending the hmac hash to the session id offer any benefit above and beyond simply setting a version 4 uuid to the cookie? My thought was that I could verify the hmac signature using my key before pinging my db to check if the session id was expired. This would cut down trips to my db if someone were trying to guess at session id's.
2. Is sha512 overkill for hashing my session id? My understanding is that it should be faster on a 64 bit machine.
3. Is appending the hashed bytes array to the session id bytes array, base64 encoding and stringifying the result the proper way of storing this information in a cookie?
4. Is $ openssl rand -base64 64 the proper way of generating a key for my purposes? Based on this discussion, my understanding is that my key length should optimally be between 64 and 128 bytes.
5. Anything else you want to add? Anything I've overlooked?

Thanks for your input. Cheers!

Answer 1

1. Does appending the hmac hash to the session id offer any benefit above and beyond simply setting a version 4 uuid to the cookie?

As you found out yourself, The main benefit is eliminating the database query for authenticating the cookie.

2. Is sha512 overkill for hashing my session id? My understanding is that it should be faster on a 64 bit machine.

The storage/bandwidth constraint is probably more significant than the speed constraint, as cookies are limited to 4K. So as a general design guideline it would be better to use a 256 bit hash. You can achieve that by using only 256 bits from the hash generated by SHA512.

3. Is appending the hashed bytes array to the session id bytes array, base64 encoding and stringifying the result the proper way of storing this information in a cookie?

This is not really a cryptography question but a software engineering question. In a nutshell, you'd want the cookie to be formatted such that you and others will be able to debug problems and fix your code even long into the future.

4. Is $ openssl rand -base64 64 the proper way of generating a key for my purposes? Based on this discussion, my understanding is that my key length should optimally be between 64 and 128 bytes.

Once again a software engineering question. Assuming you write your code in some programming language other than bash, you're better off using a cryptography library for this language. As for the key length, 32 bytes (256 bits) should be enough.

5. Anything else you want to add? Anything I've overlooked?

Try looking at the implementation of established libraries. Not sure what you want to use this for and which language you'll be using, so it is hard to give the right recommendation. One Python example that pops into mind is this but once again maybe you're into a different use case.