| 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? |
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.
> 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.
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.