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 at http://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 -~----------~----~----~----~------~----~------~--~---
