[stouset]

To avoid the problem of storing the token's hash, you have introduced:

  * parsing a structured cookie, vs a meaningless 128-bit string
  * securely storing and managing a secret HMAC key (which may be used to forge or modify credentials)
  * securely verifying an HMAC using a constant-time string comparision

So what, exactly, is the benefit of your proposal over mine? You've removed the (useful) distinction between an authentication token and the user's session. You've introduced significant additional complication and moving components. And you've increased the attack surface for security vulnerabilities. For what?

Doing all that to store a 32-bit integer is somehow less hassle than hashing and storing a 128-bit string?

[jessaustin]

you have introduced: parsing a structured cookie, vs a meaningless 128-bit string

You're going to need some logic for dealing with session, user, etc. metadata. Stipulating that parsing metadata out of a cookie is in some sense harder than reading it from a DB, keeping it in the database requires more storage (in addition to the 128-bit hash), more syncing among the various masters and slaves, and higher security. (An attacker who gets a DB dump can't see account metadata that isn't stored in the DB. Sure I'm storing a counter but what can he do with that?)

securely storing and managing a secret HMAC key

How do you run an online service without doing key management? Whatever techniques you use for your other keys, use them for this key too. It isn't as if we need a separate key for each user.

You've removed the (useful) distinction between an authentication token and the user's session.

I don't understand this claim. If I want to generate a new token for the current session, what's stopping me?

And you've increased the attack surface for security vulnerabilities.

Because HMAC collisions are easy now? I've moved some things around, but I'd say there is a tradeoff between the CAP costs of the "store everything" technique you propose and the slightly more involved validation process I describe. It's cool if you prefer your method for your situation, but can't we admit that "I'm going to describe best practice" was a bit overstated?

[stouset]

> Because HMAC collisions are easy now?

When you get the details wrong? Relatively so. And even experienced people get this shit wrong more often than they get it right. Rails had this vulnerability. Google's KeyCzar had this vulnerability. The average, non-crypto-enthusiast has effectively zero chance of getting this right out of the box.

Comparing server-computed hashes is inherently safer and less error-prone than comparing client-controlled HMACs.

  * https://github.com/rails/rails/commit/5e6dab8b34152bc48c89032d20e5bda1511e28fb
  * http://rdist.root.org/2009/05/28/timing-attack-in-google-keyczar-library/

> but can't we admit that "I'm going to describe best practice" was a bit overstated?

Not when it is accepted as best practice.

  * http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practice/
  * http://stackoverflow.com/questions/549/the-definitive-guide-to-forms-based-website-authentication

The only difference between my description is I do not store the username with the cookie; it is unnecessary and confers no discernable security benefit. I also avoid associating multiple remember-me tokens with a user, so an attacker who intercepts one must use it before the user next logs in.

Is your approach wrong? No. But it is more difficult for the average programmer to do securely and correctly, and confers few (if any) real benefits.

[jessaustin]

Thanks for the thoughtful responses!