Re: [google-appengine] Re: gaeutilities sessions, plz to help a n00b
On 22 September 2011 11:26, bowman.jos...@gmail.com wrote: > The security is the rotating session token. > It works basically like this. A session token is valid for x seconds, and > then a backlog of x tokens are considered valid. The reason that multiple > tokens are valid is to support sites using ajax requests which may have > request/response out of sequence with each other. > Avoiding taking multiple requests per page view into account, and just doing > a single page/response scenario here's how it happens. This model also > assumes that each page view is generating a new token, that's not required > as you can make the token expiration as long as you want for your > application. > You request a page, which generates a session. Session token is set in a > cookie. > Next page request, the token is valid, but expired. A new cookie is set with > a new session token. > Next page request, same thing. > Now, if you lock your user profile to only accepting one session, then > hijacking will create a scenario where either the hijacker or user loses > their session. So.. > User creates session, get's token. > Hijacker sniffs token, connects using it, and get's another token. > User makes a request, generating a new token. > Hijacker connects still using the token they had, which generates a new one. > ... > Eventually either the user or hijacker has a token that's expired so a new > session needs to be created. > If it's the user, when they log in they invalidate the session the hijacker > is using and reclaim their access. > Now, it's not fool proof. If the hijacker is using a complicated enough > system they can keep sniffing and resetting their cookies with the victims > tokens. They can at least have some access time on the users account. They > can also just sniff again to jump back on the session when they get kicked > off. There's no way to make it truely secure, just more difficult. Ok, that makes sense. > The biggest problem with gaeutilities though is it's currently pretty much > unsupported. I've stopped using appengine and with having 2 kids now I don't > have time to dedicate to a project I'm not using. I learned python writing > gaeutilities, and have since figured out ways to improve the performance > - https://github.com/joerussbowman/gaeutilities/issues/2 Oh, totally understand. > I'm open to pull requests, or even to someone forking the project and > continuing it. I'd be happy to act as an advisor or anything required to > assist as long as the contributors can deal with my limited availability. If > anyone just wants to fork the entire project and carry it on as long as I'm > comfortable with the approaches taken I'd even point everyone to it. The > only qualification I have is that security remain a primary motivator of > design. Of course if it's a fork of my code and ideas I'd also like to > continue to receive credit. > Well, if I begin to run into issues with it that I need to patch myself, I'll yell out, maybe get involved. Thanks for the awesome library though, it really is smooth to use. Great stuff. -- Emlyn http://my.syyn.cc - Synchonise Google+, Facebook, WordPress and Google Buzz posts, comments and all. http://point7.wordpress.com - My blog Find me on Facebook and Buzz -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
Re: [google-appengine] Re: gaeutilities sessions, plz to help a n00b
The security is the rotating session token. It works basically like this. A session token is valid for x seconds, and then a backlog of x tokens are considered valid. The reason that multiple tokens are valid is to support sites using ajax requests which may have request/response out of sequence with each other. Avoiding taking multiple requests per page view into account, and just doing a single page/response scenario here's how it happens. This model also assumes that each page view is generating a new token, that's not required as you can make the token expiration as long as you want for your application. You request a page, which generates a session. Session token is set in a cookie. Next page request, the token is valid, but expired. A new cookie is set with a new session token. Next page request, same thing. Now, if you lock your user profile to only accepting one session, then hijacking will create a scenario where either the hijacker or user loses their session. So.. User creates session, get's token. Hijacker sniffs token, connects using it, and get's another token. User makes a request, generating a new token. Hijacker connects still using the token they had, which generates a new one. ... Eventually either the user or hijacker has a token that's expired so a new session needs to be created. If it's the user, when they log in they invalidate the session the hijacker is using and reclaim their access. Now, it's not fool proof. If the hijacker is using a complicated enough system they can keep sniffing and resetting their cookies with the victims tokens. They can at least have some access time on the users account. They can also just sniff again to jump back on the session when they get kicked off. There's no way to make it truely secure, just more difficult. The biggest problem with gaeutilities though is it's currently pretty much unsupported. I've stopped using appengine and with having 2 kids now I don't have time to dedicate to a project I'm not using. I learned python writing gaeutilities, and have since figured out ways to improve the performance - https://github.com/joerussbowman/gaeutilities/issues/2 I'm open to pull requests, or even to someone forking the project and continuing it. I'd be happy to act as an advisor or anything required to assist as long as the contributors can deal with my limited availability. If anyone just wants to fork the entire project and carry it on as long as I'm comfortable with the approaches taken I'd even point everyone to it. The only qualification I have is that security remain a primary motivator of design. Of course if it's a fork of my code and ideas I'd also like to continue to receive credit. -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/T4Xaaa3DXFQJ. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
Re: [google-appengine] Re: gaeutilities sessions, plz to help a n00b
On 21 September 2011 01:41, bowman.jos...@gmail.com wrote: > The purpose of restricting logins to one session is to avoid session > hijacking. gaeutilities has features that help your site avoid session > hijacking which have been made even easier with tools like Firesheep > - http://codebutler.com/firesheep > Since (as of last I checked) you can't use ssl when using your own domains > cookie sniffing is simple for appengine apps. I don't know if I'm understanding this; why would that help? Wouldn't a sidejacked session look exactly like the currently logged in user anyway? How does restricting logged in users to always use the same session help here? What it would do, I guess, is allow you to keep stuff like profile info in the session, and have it immediately available on login. > Sure, other libraries are faster, and if all you care about is performance, > then I'd suggest using them. The only reason to choose gaeutilities is it > was written with security prioritized over performance, therefore is more > secure than the other libraries. Not to say it's secure, without ssl it's > not truly secure, but it's much more difficult to spoof a gaeutilities > session if configured correctly. I'm sticking with gaeutilities for now, because the security looks pretty solid. > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/google-appengine/-/XWaPWJ54gt8J. > To post to this group, send email to google-appengine@googlegroups.com. > To unsubscribe from this group, send email to > google-appengine+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > -- Emlyn http://my.syyn.cc - Synchonise Google+, Facebook, WordPress and Google Buzz posts, comments and all. http://point7.wordpress.com - My blog Find me on Facebook and Buzz -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
[google-appengine] Re: gaeutilities sessions, plz to help a n00b
The purpose of restricting logins to one session is to avoid session hijacking. gaeutilities has features that help your site avoid session hijacking which have been made even easier with tools like Firesheep - http://codebutler.com/firesheep Since (as of last I checked) you can't use ssl when using your own domains cookie sniffing is simple for appengine apps. Sure, other libraries are faster, and if all you care about is performance, then I'd suggest using them. The only reason to choose gaeutilities is it was written with security prioritized over performance, therefore is more secure than the other libraries. Not to say it's secure, without ssl it's not truly secure, but it's much more difficult to spoof a gaeutilities session if configured correctly. -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/XWaPWJ54gt8J. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
