1
votes

Instead of stroing plain text passwords, we use a strong hashing function with high computation cost and random salt to thwart rainbow attacks etc.

But when a user is in a session, typically his or her username is stored along with a hash of their password as a cookie to authenticate the sesssion. If the user's browser cookie space is compromised, doesn't an attacker obtain an easier target of cracking the username+ session hash, instead of username + pass hash?

In Django for example, passwords are hashed with PBKDF2 or bcrypt, but session hashes use a less complex HMAC and no random salt. Is this a security issue? If yes, what is the right way to handle sessions?

1

1 Answers

0
votes

For each session, I suggest to use dedicated SessionID - random long 128bit value. And, keep session key as:

username:SessionID:hash

where

hash = sha1(SessionID|username|client_IP|secret_server_side_password);

Every time, when you receive cookie, you need again compute hash, and compare with received one.

As result, this cookie is useless after session is closed (mismatch SessionID). Moreover, if cookie will be stolen from active session, server can figure out attack with stolen cookie from another computer, because of client_IP from real client will be different to actual client_IP.

Of course, if ClientIP is changed, session automatically will be disconnected.

Alternative - using authentication system, based on client's SSL certificates, for example - emcSSL.