Hacker News Reader

Comment by Vendan | Hacker News Reader

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

View on HN

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

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.

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

So you just removed the ability to have a "Log me in forever" checkbox.

A expiry date system is literally impossible to revoke without somehow maintaining a list of valid or invalid cookies, and by that point, you are hitting a database for each cookie.

So, one way, you don't have as much control, and you can't revoke a stolen cookie with potentially high level access rights. The other way, you are replicating a db backed session, and heaping complexity on top of it.

If we are dealing with a subset of bad cookies, then I suppose it becomes a hard question of what-to-do. We could put something into the code to distinguish and then require a minimum last good date of some sort. It is messy and I wouldn't want to do that, but really I just want to point out that your insistence on it being "impossible" just isn't true. If we just let ourselves revoke everything, then it is much simpler. I wonder how the "known subset of bad cookies" situation arises. I suppose it could, but you could in turn release an announcement telling your users that for all of their protection you are requiring that they login again, insert a minimum required date and move on with life. There are plenty of ways to deal with the situation and none of them are impossible.

Really? Could you try actually reading what I've written?

    impossible to revoke without somehow maintaining a list of valid or invalid cookies

Completely true. A minimum date like you are saying is still "some kind of list of valid or invalid cookies". Or are you going to get into the semantics of "that's not a list"? As an example of something that you can't do without tying a database into it, I've seen sites that let you log individual computers out of the system from your account page. No way to do that without a valid/not valid check in the DB.

Values are values whether or not they are in a db. It is situation dependant and probably not (happily) manageable in a large scale application. Saying things are "impossible" with such a heavy hand is a bit over the top. If my cookies have a date that is valid, then I can easily keep that bit of nasty logic in the code. I wouldn't do that personally, but it is doable. Take it easy :)

Would't we be able to avoid this if we did away with the secure cookie and replaced it with a jwt (jason web token)? This way, there is no state to maintain in the database, and authorization can expire?

there isn't much difference between a secure cookie and a JWT. Well, except that JWT is just signed, not encrypted, so your cookie contents are visible. Also, JWT has issues, https://auth0.com/blog/2015/03/31/critical-vulnerabilities-i.... The main thing is that you have added nothing by using JWT, cause you still can't expire a specific token without storing some kind of "token status" in the database.

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.

Also, you don't need to sign or encrypt the cookie if it's just a securely random session_id.

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

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.

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.

Reply on news.ycombinator.com