gaeutilities - http://gaeutilities.appspot.com/ - has a session class built specifically to work around that problem. The session id (used for matching data to the session) is never passed to the browser, rather is uses a session token system. By default a session token is valid for only 5 seconds, after which a new session token is generated. The current token, plus previous two, are stored and are valid on requests in order to not cause problems with sites who's pages may make multiple requests (AJAX oriented sites). It also includes a middleware class so you can plug it in and use it directly with memcache.
Version 1.1.1 is the current release, and the next release will include some new functionality to try and increase the performance by relying more on memcache (while still using the datastore in order to provide a completely reliable solution). It already uses both, but I'm working on cutting down the amount of writes. It's BSD licensed, open source. There are no fees or attribution requirements for it's use. This will not provide you with a login system. However, it does plug directly into django using the middleware so you can use django's authentication system. I in fact am currently using it, django, and the appenginepatch project - http://code.google.com/p/app-engine-patch/ - with some custom backends to handle OpenId and Oauth authentication for my user management system. On Jan 23, 4:16 pm, MajorProgamming <sefira...@gmail.com> wrote: > "Javascript on your login form should first hash the password, then > hash the result with a salt - say the session id" > I assume that's only true if I opt out of SSL? > > "That way the contents of the cookie are no use to anyone, all useful > info > is stored in memcache, where attackers can't get it." > But can't the attackers simply spoof a request with that session id in > the cookies? > > On Jan 23, 4:01 pm, Greg <g.fawc...@gmail.com> wrote: > > > First, if you are not a security expert, consider using Django's > > authentication framework. Online security is not easy - there are a > > lot of things you have to get right, and missing just one of them > > means you've failed. > > > I have a reasonable amount of experience with online security, so I > > built my own authentication system on top of gmemsess, a memchache- > > backed session object. Unfortunately my code isn't modular enough to > > publish, but here are a few pointers... > > > - SSL is always good, because it means anyone with access to your > > comms can't easily see what you are doing. However, it isn't crucial, > > as long as your customers can live with the unlikely event of someone > > sniffing their traffic - a good authentication scheme will prevent > > attackers sniffing passwords, although everything they do after > > logging in may be visible. > > > - Cookies are far more convenient than trying to pass a session ID > > with every request. Your cookie should contain a single random ID, > > which your app then uses to find the session object in memcache. That > > way the contents of the cookie are no use to anyone, all useful info > > is stored in memcache, where attackers can't get it. > > > - Store a hash of the password on appengine, not the password itself. > > This means admin cannot steal passwords, as well as allowing for safe > > transport of the password. > > > - Javascript on your login form should first hash the password, then > > hash the result with a salt - say the session id. The extra salted > > hash prevents a sniffer from simply sending the hash to login, and > > also guards against using rainbow tables to discover the password. > > Make sure you destroy the field containing the original password, so > > it isn't sent in clear along with the hash! > > > - On appengine, hash the stored password hash with the salt and > > compare with the sent hash - they should be the same. > > > - I usually disable the account if I get three wrong passwords, to > > prevent dictionary attacks. This requires some admin work to handle > > users who've been locked out, but means you don't need to implement > > captchas. > > > - Authentication is only the first step - you need to keep security at > > the top of your agenda throughout the whole application. For instance, > > if you have a url like fox.delete?id=123 that deletes a user's fox, > > always check that 123 actually belongs to this user. Otherwise users > > could delete other user's foxes by retyping the url. > > > gmemsess is athttp://code.google.com/p/gmemsess/ > > > Cheers! > > Greg. > > > On Jan 24, 8:42 am, MajorProgamming <sefira...@gmail.com> wrote: > > > > I am currently working on a App that requires that I use a custom sign > > > in method. > > > > I was wondering if there are any security flaws I should be aware > > > of... > > > > Also: > > > > I was wondering if I must use SSL for proper security? > > > > Is the best way to maintain sessions through using cookies? > > > > Do I have to perform some sort of check on the cookie even though I'm > > > using SSL? If so should I maybe use a separate hash cookie? > > > > Is directly writing cookies to the "set-cookie" header and retrieving > > > them by parsing the "cookie" header, okay? Or is there a security flaw > > > I should be aware of? > > > > Thanks for all your help! --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
