3 ms·

This system looks overly complex to me. What I use is: Cookie = (user id, timestamp of cookie, random number, hash(rest of cookie contents, user password from

by dfox 16y ago

This system looks overly complex to me. What I use is: Cookie = (user id, timestamp of cookie, random number, hash(rest of cookie contents, user password from database (in whatever encrypted form it's there)) With hash being something like HMAC-SHA1 with per-application key. Purpose of signing encrypted password together with all other data is to invalidate persistent login cookies when user changes password. Timestamp is there as to accommodate expiration of cookies in secure manner. This system has large advantage in that you don't have to store any additional data pertaining to persistent logins.

tptacek 16y ago
(1) I don't know what the value of exposing any plaintext in a security cookie is. (2) I don't know what the value in having structured data, encoded or not, in a front-end security cookie; you are virtually always better with an opaque random number token. (3) If you are going to play thermonuclear chicken with cryptography (point me to any code you wrote to generate and verify that token), I don't know what the point of a per-app HMAC key is; you are better off with a server-side per-cookie HMAC key. (4) You haven't protected the timestamp, and so cannot do secure cookie expiration. (5) The random number in that design doesn't appear to do anything.
- dfox 16y ago
  Whole idea is that with opaque random number token requires having some database of valid tokens while this design does not. All data that this scheme exposes (user id, cookie creation time) as plaintext are probably going to be exposed anyway by normal operation of application or in metadata of said cookie. Timestamp is protected by the HMAC (which may not be entirely clear from my previous description). And yes, the random number does not do anything significant and is probably useless. My reasoning was that it makes the structure of plain-text data slightly less evident from the cookie contents.
  - tptacek 16y ago
    The reason not to expose plaintext in a cookie is not simply that it discloses things, but that it creates opportunities for bugs on the serverside. Virtually everybody reading this thread would be far better served by `head /dev/random | openssl sha1` than by any other scheme.

by dfox 16y ago

tptacek 16y ago

(1) I don't know what the value of exposing any plaintext in a security cookie is. (2) I don't know what the value in having structured data, encoded or not, in a front-end security cookie; you are virtually always better with an opaque random number token. (3) If you are going to play thermonuclear chicken with cryptography (point me to any code you wrote to generate and verify that token), I don't know what the point of a per-app HMAC key is; you are better off with a server-side per-cookie HMAC key. (4) You haven't protected the timestamp, and so cannot do secure cookie expiration. (5) The random number in that design doesn't appear to do anything.

dfox 16y ago
Whole idea is that with opaque random number token requires having some database of valid tokens while this design does not. All data that this scheme exposes (user id, cookie creation time) as plaintext are probably going to be exposed anyway by normal operation of application or in metadata of said cookie. Timestamp is protected by the HMAC (which may not be entirely clear from my previous description). And yes, the random number does not do anything significant and is probably useless. My reasoning was that it makes the structure of plain-text data slightly less evident from the cookie contents.
- tptacek 16y ago
  The reason not to expose plaintext in a cookie is not simply that it discloses things, but that it creates opportunities for bugs on the serverside. Virtually everybody reading this thread would be far better served by `head /dev/random | openssl sha1` than by any other scheme.