Hashing a session fingerprint really necessary?

Question

Please read this THOUROUGHLY before voting...

So I have seen a lot of session management classes that create a fingerprint via concatenation of user agent and a couple of ip blocks or whatever. They seem to also add a salt and then hash this fingerprint before storing it in a session variable.

This fingerprint generation typically happens every request in order to verify that the current user of the session is in deed the original session user. This is why I am wondering, is the salt and hash really necessary on something like this?

If a hacker can get onto your filesystem to see your session file contents, aren't you already hosed at that point?

Any info greatly appreciated.

Answer 1

Most of it makes sense, but the hashing and salting makes no sense.

If you tie the session to an IP address, then it becomes a lot harder to hijack into a session. This is something I recommend doing, but you don't need to be utterly strict about it. You can just tie to the first three parts of the IPv4 or so. The choice is yours. The more strict IP check the more secure it is, but the less convenient it is for users.

And as for tying the session based on the user agent, that may also help. It must be realized that if you work on an unencrypted channel (HTTP for example), then the user agent check is less useful as it can be reproduced by the intruder as well.

When it comes to salting and hashing, that is useless. They add no strength to your identity checks. The only thing they do is complicate your design. For this matter, I believe they lower your level of security.

As always, a few rules to keep in mind:

• Use strong session identifiers. This means use good random sources and make sure there are enough bits.
• Tie the session to an IP, at least to some extent.
• Tie the session to a user agent, if possible.
• Use SSL/TLS. Without it, theoretically all session systems are insecure.
• Secure your session storage. Whether it's filesystem based or database based.

Answer 2

I can think of two cases where it would be useful:

1. When the session data is stored client-side. (Like in a cookie.) So, I'd be prevented from taking my cookie to another computer, and I'd be prevented from making up my own cookie contents. (Ok, so this is not a very likely scenario...)
2. When the session data is stored in some shared server-side resource (i.e., /tmp) and is vulnerable to snooping. In this case, if the snooper is able to see the contents of the session, they'll still be unable to fake a connection to that session because they don't know what data went into the fingerprint.