"If that's what's coming from the browser, > then anyone else can just sniff that hash and send it as the password > with the username." Not really, because you can simply tell the client to hash the password with some random number (or string) that you sent to the browser... Otherwise, though, you are correct.
And even if I do use openID, or the like, I also wanted to know about securing the cookie (or session), because even in such a situation they only perform the password check. The rest is in the applications hands. On Jan 23, 10:50 pm, "bowman.jos...@gmail.com" <bowman.jos...@gmail.com> wrote: > By the way, relying on javascript to handle hashing passwords and such > isn't a reliable solution. If that's what's coming from the browser, > then anyone else can just sniff that hash and send it as the password > with the username. In the end you're relying on data from the client > being secure, which is bad. > > I'd suggest, if you don't want to use the Google User API, you look > into still using other ID providers, such as OpenID, Oauth, or > Facebook connect. They will handle the login via SSL on their end, and > the account validation would happen via urlfetch between your > application and the provider, leaving no traffic to be sniffed on the > users network. > > If you really need a unique user system, I suppose you could set up a > VPS server and have it act as an OpenID provider. One thought that > just hit me as I writing this up is you could also use the build in > application.appspot.com ssl that google provides you to handle the > login by making it an OpenID provider. I believe there's a sample > application out there for making an OpenID provider on GAE. Then your > application, if you're using your own domain name, could urlfetch to > itself for that portion of the authentication, in order to get the > cookie domain set correctly for your sessions. > > This is something that would make an interesting little project, I > wish I had time for. > > On Jan 23, 10:42 pm, "bowman.jos...@gmail.com" > > <bowman.jos...@gmail.com> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
