5 ms·

without reference to this project - Perhaps you meant storing all session data is a bad idea versus just an ID? (If so, I'm with you) If not - how would you

without reference to this project - Perhaps you meant storing all session data is a bad idea versus just an ID? (If so, I'm with you) If not - how would you identify an authenticated user? Or, how would you look up all their relevant session data in the DB?

Vendan 11y ago
"securecookies" is a term used, at least in the context of github.com/gorilla/sessions, to refer to a session storage based on encrypting all of the session data and sending it as a cookie. That means all of your session data, including if the user is authenticated and even which user it is, is sent to the browser and back to the server on the next (and subsequent) request(s). This is an interesting concept, but IMHO, rather flawed. About the only valid use is for small micro-apps that don't have any server side persistent storage. A db based session, which really wouldn't be that hard to set up with github.com/gorilla/sessions, would just send a randomly generated session id to the client in a cookie, save the data in the db, then read that data back out of the db on the next request.
- Jailbird 11y ago
  Ah - yep, I've betrayed I'm not as familiar with gorilla as I might like to be. Yet. The way you've described things is how apps I'm familiar with do it (the latter way.) Thanks for clarifying.
- danneu 11y ago
  Also, you don't need to sign or encrypt the cookie if it's just a securely random session_id.
  - elithrar 11y ago
    > Also, you don't need to sign or encrypt the cookie if it's just a securely random session_id. You should authenticate it anyway, to prevent someone from trying to brute force ID generation (and therefore masquerading as another user). Otherwise all hope rides on you using a sufficiently long (CSPRNG-sourced) ID. Authenticating it is good practice.
    - Vendan 11y ago
      Authentication really doesn't do anything that extending your id key by that number of bits wouldn't do, i.e. a 32 byte random ID is just as hard to collide as a 16 byte random ID and a 16 byte signature. Technically, if there are any weaknesses in your signature, they may end up making your ID+signature easier to collide. Just going with a pure random ID means 1 less key that you have to keep out of source control.
    - danneu 11y ago
      If you don't trust your random numbers to begin with, signing one with another doesn't help you. As Vendan points out, it's worse. Just keep it simple. > to prevent someone from trying to brute force ID generation That's the point of using a large securely-random number. It's beautifully simple to give the client nothing more than a large random number to authenticate them.
- elithrar 11y ago
  > That means all of your session data, including if the user is authenticated and even which user it is, is sent to the browser and back to the server on the next (and subsequent) request(s). This is an interesting concept, but IMHO, rather flawed. About the only valid use is for small micro-apps that don't have any server side persistent storage. I'm curious: what do you consider particularly flawed? DB backed sessions with simple ID-storing cookies suffer many of the same problems, with the primary issue being that you can MitM the cookie and masquerade as another user if not served over HTTPS. DB (SQL, Redis, et. al) backed sessions are nice if you are storing genuine data (i.e. form data), because cookies typically have a 4KB per domain limit in most browsers. If you are just storing a user ID, email address and/or admin flag, the cookie is authenticated (to prevent modification of those values) and served over HTTPS (only, ever) then there isn't an immediate problem there. You also don't have to worry about hitting your DB for each request - Redis is real quick, but (without hard numbers) I don't expect that sending 1KB of cookie header data would be slower either.
  - Vendan 11y ago
    Keep in mind, your authenticated cookie is exactly as easy to MITM as a ID storing cookie, and potentially more dangerous. A session can be deleted from the db, and then that session cookie is dead. An authenticated cookie is good forever, unless you start putting expiration times or something similar. Issue with that is now you have to make sure it's all done correctly, and there's no bugs that may make the cookie good forever/impossible to revoke. Whereas, you get that kinda stuff for free with a db backed session, just delete the session and they are logged out, period.
    - 4ydx 11y ago
      You could always, you know, change the code (which is simple) so that an "infinite" expiry date is no longer valid. Line 215. https://github.com/gorilla/securecookie/blob/master/securecookie.go https://github.com/gorilla/securecookie/blob/master/secureco... As for "impossible to revoke" well if you have control over your server you can do whatever you like so this falls into the very not-at-all-impossible category. As a baseline as long as there is no personal information in the "secure cookie" there really is no issue at all.

Vendan 11y ago

"securecookies" is a term used, at least in the context of github.com/gorilla/sessions, to refer to a session storage based on encrypting all of the session data and sending it as a cookie. That means all of your session data, including if the user is authenticated and even which user it is, is sent to the browser and back to the server on the next (and subsequent) request(s). This is an interesting concept, but IMHO, rather flawed. About the only valid use is for small micro-apps that don't have any server side persistent storage. A db based session, which really wouldn't be that hard to set up with github.com/gorilla/sessions, would just send a randomly generated session id to the client in a cookie, save the data in the db, then read that data back out of the db on the next request.

Jailbird 11y ago
Ah - yep, I've betrayed I'm not as familiar with gorilla as I might like to be. Yet. The way you've described things is how apps I'm familiar with do it (the latter way.) Thanks for clarifying.
danneu 11y ago
Also, you don't need to sign or encrypt the cookie if it's just a securely random session_id.
- elithrar 11y ago
  > Also, you don't need to sign or encrypt the cookie if it's just a securely random session_id. You should authenticate it anyway, to prevent someone from trying to brute force ID generation (and therefore masquerading as another user). Otherwise all hope rides on you using a sufficiently long (CSPRNG-sourced) ID. Authenticating it is good practice.
  - Vendan 11y ago
    Authentication really doesn't do anything that extending your id key by that number of bits wouldn't do, i.e. a 32 byte random ID is just as hard to collide as a 16 byte random ID and a 16 byte signature. Technically, if there are any weaknesses in your signature, they may end up making your ID+signature easier to collide. Just going with a pure random ID means 1 less key that you have to keep out of source control.
  - danneu 11y ago
    If you don't trust your random numbers to begin with, signing one with another doesn't help you. As Vendan points out, it's worse. Just keep it simple. > to prevent someone from trying to brute force ID generation That's the point of using a large securely-random number. It's beautifully simple to give the client nothing more than a large random number to authenticate them.
elithrar 11y ago
> That means all of your session data, including if the user is authenticated and even which user it is, is sent to the browser and back to the server on the next (and subsequent) request(s). This is an interesting concept, but IMHO, rather flawed. About the only valid use is for small micro-apps that don't have any server side persistent storage. I'm curious: what do you consider particularly flawed? DB backed sessions with simple ID-storing cookies suffer many of the same problems, with the primary issue being that you can MitM the cookie and masquerade as another user if not served over HTTPS. DB (SQL, Redis, et. al) backed sessions are nice if you are storing genuine data (i.e. form data), because cookies typically have a 4KB per domain limit in most browsers. If you are just storing a user ID, email address and/or admin flag, the cookie is authenticated (to prevent modification of those values) and served over HTTPS (only, ever) then there isn't an immediate problem there. You also don't have to worry about hitting your DB for each request - Redis is real quick, but (without hard numbers) I don't expect that sending 1KB of cookie header data would be slower either.
- Vendan 11y ago
  Keep in mind, your authenticated cookie is exactly as easy to MITM as a ID storing cookie, and potentially more dangerous. A session can be deleted from the db, and then that session cookie is dead. An authenticated cookie is good forever, unless you start putting expiration times or something similar. Issue with that is now you have to make sure it's all done correctly, and there's no bugs that may make the cookie good forever/impossible to revoke. Whereas, you get that kinda stuff for free with a db backed session, just delete the session and they are logged out, period.
  - 4ydx 11y ago
    You could always, you know, change the code (which is simple) so that an "infinite" expiry date is no longer valid. Line 215. https://github.com/gorilla/securecookie/blob/master/securecookie.go https://github.com/gorilla/securecookie/blob/master/secureco... As for "impossible to revoke" well if you have control over your server you can do whatever you like so this falls into the very not-at-all-impossible category. As a baseline as long as there is no personal information in the "secure cookie" there really is no issue at all.