NIniftich·Aug 30, 2016
For a voting URL, you want some value that the server can calculate based on info it has, and that's sufficiently large to not be brute-forceable, and sufficiently unpredictable to not be enumerable. They are 'capability URLs' [1] like a private Google Docs link, or a 'click here to reset your password' token. So 'auth' parameter in the URL is likely the output of a deterministic function of the user and a server-side secret, and possibly a time factor; you can accomplish this with an HMAC.
HOTP [2] and TOTP [3] are two concrete schemes that use this method and truncate to a human-friendly size at the end to use it as part of a challenge-response, but you don't want to truncate this here because then the range of values would be brute-forceable. So it's likely just the output of a LARGE-HMAC(secret-key, MixingFunction(user, timewindow)).
Read the rest
Or, if time isn't present, then LARGE-HMAC(secret-key, user).
Since the voting URLs are server-generated, the Cookie value must be unrelated. Logging in with a web browser, copying the cookie, and mimicking the same cookies with curl, I'm logged in with curl, but changing either my username or my token I'm not logged in. The opaque value in the cookie is consistent with what you'd expect from a Session ID, which is not surprising. I'm speculating, but the addition of the username may serve as a countermeasure against session guessing attacks (like, being able to quickly distinguish a tampered Session ID from a good one, like these other apps try to [4][5]), or may simply be an implementation detail.
[1] https://www.w3.org/TR/capability-urls/
[2] https://en.wikipedia.org/wiki/HMAC-based_One-time_Password_A...
[3] https://en.wikipedia.org/wiki/Time-based_One-time_Password_A...
[4] http://stackoverflow.com/questions/18751565/detecting-rails-...
[5] https://github.com/expressjs/session/issues/176