Lots of fuss recently over how one should store users’ passwords in a database. One angle that hasn’t received much attention, and which I myself hadn’t thought much about, is how to store cookies such as auth tokens. I’m assuming for this post that we’re using the technique of generating a random string, setting it as a cookie, and then saving a copy in the database. When the visitor returns, they send the cookie and you compare with the value stored in the database. (Some frameworks set an HMAC signed token instead; they should be safe from the problem I’m about to describe.)

The problem is that these tokens are equivalent to passwords. They let anyone who has one login. If someone steals your auth token database, they can login as any user, just as if they had stolen a plaintext password database. They also may be vulnerable to a timing attack during comparison, depending on what you do and who you believe. The solution is to treat them just like passwords. Hash them before storing in the database. Just once should be enough; if your tokens aren’t at least 128 bits of random data, you have other problems. Then every time you get a cookie from the user, hash before looking up in the database. Now if someone steals your database, they have a lot of work ahead of them trying to recreate the token they need to submit to login.

Alternately, using HMAC signed cookies should be sufficient, but there have been several vulnerabilities related to their implementation, so I remain cautious.