Currently, upon login, a user gets a cookie that contains the user ID and a salted, hashed password. That's a little more secure than what WordPress does because of the salting and because we use a more expensive hashing algorithm, but it has the same flaw the WordPress code has in that the cookie hash is a hash of the password hash, so it's simple to go from the hashed password to a valid cookie.
The solution is to set cookies for sessions. These can contain additional information such as expiration time (good), session IP address (often problematic), etc.
We should also consider doubly-hashing the passwords in our DB and having the session cookie contain the once-hashed version. This way, both are secure, but there's no feasible way to go from the DB version to generating a valid cookie. This way, when the database is compromised, the attacker doesn't know your password nor can she create a valid login cookie.
Switching the location of the double-hashed passwords seems like a decent first step.
At a recent SANS training class (Security 519) [1], it was strongly recommended that developers use the database to store persistence for user sessions between page loads. The client stores only some session token (possibly in a cookie), and that token is an identifier for a row in the DB that contains, at least, the following additional data: * first three octets of IP address * user agent string * timestamp of when the session started
The first three octets of the IP help ensure that the user is coming from the same network, while still permitting proxy servers. The user agent string should never change between sessions: if it does, immediately log out the user, delete the session row, and prompt for authentication.
The recommended best practice is to delete the session row from the DB when it is expired (or when the user elects to log out), so that the session cannot be reused.
I don't think this would be too hard to code. Anyone have any concerns or objections?
I asked the Gallery 2 devs about how Gallery 2 handles this, and this is what I got:
* it binds sessions to a client signature * we accept a client if it has the same IP as the client that started the session * or if the client has the same user-agent signature (the user-agent header) * based on my beer infected assessment sending md5(md5(password) as cookie to the client is a pretty stupid idea (just exposing anything to the client that is related to the password seems to be a bad idea) * In Gallery 2 passwords are md5+salt, and the cookie is 100% independent *for professional apps, you should go as far as using different ids internally and externally
Remember, I'm just the messenger here and I'm NO authority on this.
Switching the location of the double-hashed passwords seems like a decent first step.
At a recent SANS training class (Security 519) [1], it was strongly recommended that developers use the database to store persistence for user sessions between page loads. The client stores only some session token (possibly in a cookie), and that token is an identifier for a row in the DB that contains, at least, the following additional data: * first three octets of IP address * user agent string * timestamp of when the session started
The first three octets of the IP help ensure that the user is coming from the same network, while still permitting proxy servers. The user agent string should never change between sessions: if it does, immediately log out the user, delete the session row, and prompt for authentication.
The recommended best practice is to delete the session row from the DB when it is expired (or when the user elects to log out), so that the session cannot be reused.
I don't think this would be too hard to code. Anyone have any concerns or objections?
