4

I'm considering storing a hash of a user's session ID in our applications logs on each request. This would allow users sessions to be easily tracked back to actions in our logs.

I understand that storing this is a potential security risk, which i may be willing to consider if the risk is very low. Why is it a risk? If anyone that has access to the logs can figure out how to get a session ID, then they can essentially steal that users session and login as them without credentials.

To that end, if I was going to do this, what's the best way to do this?

Here are some things I'd like considered:

  • Which hashing algorithm should I use ? It needs to be fast.
  • What should I hash ? Session ID + Salt?
  • How risky is this? Should I just not do this?

EDIT: I'm considering just generating a GUID and adding it to a users session on session creation. Then logging this instead. That way it'd always be unique for the sessions lifetime. The problem with this is that it would add more session data and require more session memory for each user. With this approach no hashing would be required, and the user's session could still be uniquely tracked.

  • If someone can access the logs, they can access all sessions even without the logs. – ThoriumBR Aug 26 '15 at 14:56
  • Yeah that's part of the reason i wonder if there's a reasonable middle ground here - secure and fast. I just know that logs can make there way off of a system is all, and then access might not have been required. – Brad Parks Aug 26 '15 at 15:08
6

If session identifier is randomly chosen from sufficiently big space (something like 12 bytes should be more then enough) then any non-invertible hash function (even md5) will be secure, and there will be no need for salt (rainbow tables of this size are infeasible).

To expand, problem when storing password hash is that passwords usually have very low entropy (unlike tokens, like session id for example). Besides, you do not care for other hash function properties in which md5 considered weak - attacker cannot influence his session id to collide with any user, and even if he does it will only (at best) confuse you studying the logs).

  • Great point! Our session Ids are ~ 27 chars long and are a "type 4 (pseudo randomly generated) UUID. The UUID is generated using a cryptographically strong pseudo random number generator" docs.oracle.com/javase/7/docs/api/java/util/… So that's probably good, right? – Brad Parks Aug 26 '15 at 15:39
  • and this article offers some great insight into entropy and data length for hashing too. – Brad Parks Aug 26 '15 at 15:46
  • and Java's UUID predictability is discussed here, and sounds fine by my estimation for this use case. – Brad Parks Aug 26 '15 at 16:02
  • and one last note, our session ids are actually 36 chars long. – Brad Parks Aug 26 '15 at 16:59
  • 1
    Yes, it's far out of reach to brute-force it knowing only hash. – Cthulhu Aug 26 '15 at 17:01

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.