0
$\begingroup$

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!

$\endgroup$
  • $\begingroup$ What are you trying to gain by appending hmac? $\endgroup$ – axapaxa Apr 28 '17 at 22:21
  • $\begingroup$ Verification that the cookie val was originated from my server. $\endgroup$ – adam-m-hanna Apr 28 '17 at 22:30
  • $\begingroup$ And verification of that gives you? What kind of security are you looking for? HMAC is not hacker repellent, it gives you some security assumptions, none of which are useful for cookies IMO. $\endgroup$ – axapaxa Apr 28 '17 at 23:08
  • $\begingroup$ To clarify: Why don't you use HTTPS to secure your session(s)? After all, that's what it was made for and SSL certificates aren't expensive either (some even come for free)… so there's not much reason to not use it. Your use of OpenSSL underlines that there shouldn't be a technical problem to use HTTPS either. What is stopping you from using well-vetted SSL solution(s) and what makes you reinvent the wheel instead? Reducing REDIS db load the way you are describing doesno't really seem to make much sense… but maybe I'm missing something, or I didn't grasp your actual intend. $\endgroup$ – e-sushi Apr 29 '17 at 11:28
  • 1
    $\begingroup$ @axapaxa HMAC is very useful for "stateless" session cookies. It's exactly how the API credentials for just about every large web service work. During authentication, the server encodes identity, minimal authorization info, and an expiration then HMACs the result. Now you don't need to hit a database/network cache for those details on every request. This is the reason it is used at large scale: it minimizes shared state. This "stateless" benefit is orthogonal to using HTTPS. Note: someone (maybe me by accident) edited this comment and made it nonsensical, so I deleted and re-posted. $\endgroup$ – rmalayter May 1 '17 at 4:08
1
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ Thanks so much! This really helps me understand things much better! $\endgroup$ – adam-m-hanna May 2 '17 at 17:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.