Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go-bootstrap: Generates a lean and mean Go web project

go-bootstrap.io

Post reply on HN
Print view View original

51–60 of 61 posts

Re: Go-bootstrap: Generates a lean and mean Go web project

#51

Post by Vendan »

4ydx wrote: post #50
Vendan wrote: post #47

Earlier quoted context omitted.

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 g…

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 "sec…

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.

Re: Go-bootstrap: Generates a lean and mean Go web project

#52

Post by czbond »

Vendan wrote: post #47
elithrar wrote: post #42

Earlier quoted context omitted.

> 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 sessi…

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 g…

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?

Re: Go-bootstrap: Generates a lean and mean Go web project

#53

Post by Vendan »

czbond wrote: post #52
Vendan wrote: post #47

Earlier quoted context omitted.

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 g…

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.

Re: Go-bootstrap: Generates a lean and mean Go web project

#54

Post by 4ydx »

Vendan wrote: post #51
4ydx wrote: post #50

Earlier quoted context omitted.

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 "sec…

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 b…

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.

Re: Go-bootstrap: Generates a lean and mean Go web project

#55

Post by czbond »

After fiddling with the initial rev, and having issues - I pulled your May 8 commits and this is very nice and working well! Thank you so much! I've been using a "book in progress" for better practices for go web programming (http://www.manning.com/chang/). But this was much better for me to get going! Cheers.

Re: Go-bootstrap: Generates a lean and mean Go web project

#56

Post by Vendan »

4ydx wrote: post #54
Vendan wrote: post #51

Earlier quoted context omitted.

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 b…

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 simp…

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.

Re: Go-bootstrap: Generates a lean and mean Go web project

#57

Post by danneu »

elithrar wrote: post #43
danneu wrote: post #37

Earlier quoted context omitted.

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.

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.

Re: Go-bootstrap: Generates a lean and mean Go web project

#58

Post by 4ydx »

Vendan wrote: post #56
4ydx wrote: post #54

Earlier quoted context omitted.

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 simp…

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 l…

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 :)

Re: Go-bootstrap: Generates a lean and mean Go web project

#59

Post by didip »

kristianp wrote: post #40
ejcx wrote: post #3

I like the project. You integrated a lot of well known and standard packages that people writing Go-WebApps would want, and didn't make the project super heavyweight. Very useful and still very light. I will definitely be using it, since one of my biggest problems with getting new go machines set up is going out and finding all the packages I have used in the past. On top of that, you got me another Gorilla Secure Co…

This project generates scaffolding code, that key should be generated too.

Excellent feedback! I've updated the code to randomly generate the key during bootstrap.

Re: Go-bootstrap: Generates a lean and mean Go web project

#60

Post by didip »

czbond wrote: post #55

After fiddling with the initial rev, and having issues - I pulled your May 8 commits and this is very nice and working well! Thank you so much! I've been using a "book in progress" for better practices for go web programming ( http://www.manning.com/chang/ ). But this was much better for me to get going! Cheers.

Glad to hear that the project helps!
Post reply on HN