Any gotchas I should be aware of regarding this approach to persistent logins ("Remember Me")?

Question

This web application will have a database table with columns uniqueid (64-bit int autoincrement field; key), token (64-byte binary field), and an accountid.

After logging in with "Remember Me" checked, a random token will be generated. Then the SHA-512 hash of this token will be inserted into the database and the generated uniqueid retrieved. A cookie that contains the uniqueid and unhashed token is sent to the client.

Every time a user visits the page with the cookie, the cookie's uniqueid and its token's SHA-512 hash with be checked against the database. If there is a row that matches the uniqueid, and that row's token hash matches the token hash, log in the user with the row's accountid. After every authentication attempt made by the cookie, delete the row that uses the old uniqueid and, if the authentication was successful, generate a new random token. Then the SHA-512 hash of this token will be inserted into the database and the generated uniqueid retrieved. A cookie that contains the uniqueid and unhashed token is sent to the successfully authenticated client.

I will be using the techniques described here as well. All failed cookie authentications will have the cookies set to blank values and expiration date set to sometime in the past.

I believe this method would address a few concerns regarding cookies. Namely:

1. The token in the database is hashed so that as long as an attacker does not have write access to the database, he/she will not be able to forge cookies of all users.

2. Unique IDs are used instead of a user's account name because login credentials should never be stored in a cookie.

3. A random token is generated every time the cookie is authenticated so that if an attacker steals a cookie, it will only be valid until the user next logs in rather than for the entire time the user is remembered.

4. Cookies will be difficult to sniff because my entire application uses HTTPS.

I can further enhance security by allowing the user to specify how long he/she wants to be remembered for. The expiration date will be stored in the same database table that stores uniqueid and tokens. Every time a new cookie is created, this expiration will be sent with the cookie. If a user tries logging in with a cookie that the server deems expired but the client still holds, the log in will be denied.

I believe this solution is reasonably secure, but are there any pitfalls or things that I have overlooked when I designed this method?

Sources:

Hash token in database

Don't store account name in cookies and use new unique id after every authentication

Answer 1

When it comes to security, reasonable is always relative. :) It is reasonable if you think it is appropriate vs. the threats you face. That said, here are a few things I'd do if it were my app and I believed I was actually going to need to protect it from attack...

• Stamp something in to the token / b/e that allows you to correlate back to the original authentication event, then log it in all cookie operations. This way you can do correlation if (when :)) people get hacked and you want to figure out what happened when.
• On the b/e, make sure you implement "invalidate all of my outstanding tokens" as a feature of the system. Then wire this in to all "suspicious" events automatically.
• Store geo information in the cookie / in the b/e with the row that corresponds with the cookie. Start by logging it. Eventually you'll want to do more. As you study people that get hacked you'll find more and more things you can do with this data. If you don't have the data, you can't learn.
• Lots of instrumentation. Lots and lots of instrumentation. Retain it for years. Everything gets an event, log everything you know in that event when it happens. Good visualization / lookup tools that you can use to figure out what happened when.

There are of course zillions more things you could do, this is just a starter list...