Comment by sehrope | Hacker News Reader

Comment by sehrope | Hacker News Reader

Remember me cookies are a specific case of some data sent to the client that the server would like to verify at a later point in time. The most direct way that comes to mind for solving this type of problem is to send the client just a random identifier and have the server look it up in a persistent store upon use.

The other way of solving it is to have the server sign whatever data is sent to the client via an HMAC. That combined with some basic serialization gets you a generic approach that you can use for all kinds of things. This also has the scalable benefit that it doesn't require a centralize persistent store.

Here's a high level summary of how we handle these use cases:

# Server -> Client (Assume server wants to round trip object X)

  1. Server serializes X to a URL friendly string (JSON + Base64 works well enough for this)
  2. Server calls generateToken(type, message, expiration) which signs the message/expiration with secretKey+type. It then returns a JSON/Base64 serialized map containing message/expiration/hmac.

# Client -> Server

  1. Client sends back the final JSON/Base64 string
  2. Server decodes and extracts the message, expiration, and hmac
  3. Server verifies the HMAC by regenerating it and comparing it against the client supplied one
  4. Server verifies the expiration date hasn't passed
  5. Server returns back the deserialized object

Couple of notes:

* The HMAC prevents the client from tampering with the message

* The 'type' field is so that tokens generated for one request type cannot be accepted somewhere else in the application. It's kind of like namespacing.

* The 'type' field does not need to be included in the message itself. It's inferred by the server based on the client request type.

* The object/message itself can be blank. In that case this becomes a secure expiring token.

Couple of possible extensions/improvements:

* If the data being sent back/forth is particularly sensitive you could also have the server encrypt either it or the entire message itself. If it's not though then it would be overkill.

* Including the requesting clients IP in the HMAC generation to further limit the set of user's it would validate against is an option as well though generally that's a bad idea. People's IP addresses change fairly often and that kills the basic use case of taking your work home with you.

This is where most cookie schemes wind up -- sending and retrieving HMACs.

I wrote my honours dissertation on an opt-in scheme that used cookies, HTTPS and javascript to track users visiting multiple websites.

What you have here is what I called "Protocol 1": the first elaboration of the naive protocol. An additional elaboration (Protocols 2 and 3) is to remove user identification from cookies entirely. Each cookie is regenerated on each HTTP request with a new ID and HMAC. This means that if a cookie is successfully harvested, its useful lifetime is limited.

There are more attacks after this. I got as far as Protocol 10; it transpires that Protocol 10 is broken anyhow. Depending on the sophistication of your attacker, there's no safe way to do what I was trying to do.

This sounds interesting. Can you provide a link to this dissertation?

Email me (in profile).

> The most direct way that comes to mind for solving this type of problem is to send the client just a random identifier and have the server look it up in a persistent store upon use.

This is my preferred approach. I generate random 128-bit integers (using a random number generator who's purpose is to be used for cryptography purposes, so it's hard to observe) and store these in Redis with a year expiry, and send them back to the client to store in a cookie. When this token in the cookie is used, the TTL on the token is reduced to 5 minutes, which lets power users up multiple tabs at once. It's the simplest, but also most robust way, I've found to deal with this.

The cleverer I try and be, the more I tend to mess these things up.

This is a good approach for a lot of things. It's the approach Flask uses for its session data by default. I wouldn't recommend it for authentication in large deployments though.

One thing that it doesn't allow for is revocation of individual tokens. Invalidating auth tokens centrally is a very useful capability to have.

Yes that's the biggest downfall and also where having a centralized persistent store wins out. The best compromise between the two I've thought of is to have a centralized store that lists revoked tokens.

Presumably there wouldn't be that many so storing the recovations alone would be more efficient. Bonus points if you add a Bloom Filter[1] in front of the revocation lookup.

In the end it's all about the use case you're solving. If the token's themselves already have a short expiration (ex: password reset token with 5 minutes to live) then revocation isn't really an issue. For something long lived and dangerous (ex: remember me token to log into my bank account) it's much more important.

[1]: http://en.wikipedia.org/wiki/Bloom_filter

Yes, a password reset token is a good example where it would be fine to used a HMACed token, and is exactly how Django handles password resets [1].

[1] https://github.com/django/django/blob/master/django/contrib/...

It's also possible to make the cookies non-exportable using a similar technique called channel binding[1], where the cookie is linked to the TLS channel it's minted over.

This is a lot more powerful than baking in the IP address when HMAC-ing the cookie but requires modification to the browser and server to get it up and running.

[1] http://www.browserauth.net/channel-bound-cookies

Reply on news.ycombinator.com