Session Handling
Matthias Bauer
in light of the current discussion about WordPress' insecure cookies
(<http://lwn.net/Articles/259204/>,
<http://trac.wordpress.org/ticket/2394>,
<http://trac.wordpress.org/ticket/5367>), I think it's time we switch to
user sessions instead of always-valid cookies.
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.
A simple implementation is outlined at
<http://trac.wordpress.org/ticket/5367#comment:3>
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.
Please help me brainstorm on this :D
-Matt
Scott Merrill
> in light of the current discussion about WordPress' insecure cookies
> (<http://lwn.net/Articles/259204/>,
> <http://trac.wordpress.org/ticket/2394>,
> <http://trac.wordpress.org/ticket/5367>), I think it's time we switch to
> user sessions instead of always-valid cookies.
> Please help me brainstorm on this :D
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?
1: http://www.sans.org/training/description.php?tid=468
--
GPG 9CFA4B35 | ski...@skippy.net | http://skippy.net/
Christian Mohn
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.