5

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.

Improve this question
2
  • If someone can access the logs, they can access all sessions even without the logs.
    – ThoriumBR
    Aug 26, 2015 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, 2015 at 15:08

1 Answer 1

Reset to default
7

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).

Improve this answer
6
  • 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, 2015 at 15:39
  • and this article offers some great insight into entropy and data length for hashing too.
    – Brad Parks
    Aug 26, 2015 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, 2015 at 16:02
  • and one last note, our session ids are actually 36 chars long.
    – Brad Parks
    Aug 26, 2015 at 16:59
  • 1
    Yes, it's far out of reach to brute-force it knowing only hash.
    – Cthulhu
    Aug 26, 2015 at 17:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .