Awesome response SRI, and with a bit of luck this will help all those hundreds of people on here who are struggling with how to implement decent security.
Ive spent months wrestling with security, after finding out that Google accounts doesnt have a good enough API for use with GWT/GAE.....and that GAE doesnt support SSL/HTTPS for custom URLs (eg in my case www.ucanzoom.com) What struck me immediately is how easy it was for you to figure out what my client side code was doing, esp given that GWT should be obfuscating the code, which I thought would me making it pretty hard to actually "read my source code"... Ill address your points individually and I would very much appreciate any further feedback you are willing to give. 1. The client side encryption is just trying to make it as hard as possible for "people like you";) to crack my password, ive had loads of people say "theres no point doing client side encryption", but my feeling is that you have to do SOMETHING on the client side, even if it does only take a determined hacker half an hour to figure it out. At least im forcing someone to consider whether or not its really worthwhile bothering to spend that time trying to crack my encryption. Even the fact that you have referred to it as "some kind of encryption" makes me smile, as you are right in that I have created what i think is a pretty tough encryption. Id be interested to hear what kinds of methods a determined hacker might use to crack it, as Im fairly happy that the only way to actually do that would be to examine the source code. I dont think that any kind of brute force will succeed, but Im reasonbly OK if brute force will work, as stated earlier in this response! Im not happy that you can find the "secret key" id forgotten to hide that... Ill get onto that ;) 2. Ive never heard of TLS, but SSL is not currently available for custom URLs on Google App Engine, which is why I cant use it. Extracting the password is something that worries me, however I am somewhat relying on the sessionID to provide a unique "connection" once the user has just logged in once (see some comments below on this) 3. I am using a well recognised encryption algorithm on the server side to actually store the passwords in Google App Engine Big table (although Im reasonbly happy about the fact that Google datastore is pretty secure in its own right) 4. I dont really understand session ID's and have not been able to find a simple explaination anywhere on the web as to how they work. Im not actually planning on using cookies initially because of the potential security issue. Is a session cookie automatically created? does it store the same sessionID as the server? 5. how does the server know if im logged in or not? Actually, from point 4, Im just guessing that you could store the session ID with a timeout. Is that how it should be done? Checking it on the client side is an efficiency thing, no point in doing an RPC call if the client side knows for sure if the session is not logged in. The client side check is more of a check that your logged out rather than a check that you are logged in.... If you can recommend a security framework that works with App Engine and custom URL's without SSL/HTTPS and has really good documentsation for complete dummies then please do let me know.... Thank you SOO much for your input Sri, its really great to have had even the feedback you have given me so far! John On 27 April 2010 04:46, Sripathi Krishnan <[email protected]>wrote: > > 1. You are doing some kind of encryption of passwords on the client > side. Its a big mistake. Its easy to figure out how its being > encrypted/hashed. In your case, the secret key is > > L87Y9*(yOFDMrsn};W/.XEPvSt]{uwl~,ozi34jQmT:@Rd)CZae2k|=6^I_+AG-[x01HBNpqUb?cJKV5fgh. > The exact algorithm used for encryption is also extractable, just needs > half > an hour of determination. > 2. Not using SSL/TLS is another big mistake. It is trivial for anybody > to see the traffic an extract the password. Your custom password encryption > algo (in 1 above) is not going to help at all. > 3. I can't tell how you are storing passwords on the server side, but > you must salt and hash your passwords. They must not be stored in a > recoverable form. Also, use a strong hash function (SHA-1, for example). > MD5 > is broken, don't use it. And please do not create your own hash function, > its not worth it. > 4. Why do you have a RPC method getSessionID()? You don't need the > sessionid in client side code. Just stick to the default session id that > your application server provides. If you want to read the session > identifier, pick it up from the cookie > 5. I see there is a javascript check to see if the user is logged in or > not. I hope you are doing it on the server side as well... Its useless to > do > the check on client side. > > To summarize - please don't build authentication/authorization yourself. > Its far easier and secure to use a framework. Once you get the basics right, > go through the Security for GWT > paper<http://groups.google.com/group/Google-Web-Toolkit/web/security-for-gwt-applications>for > additional information. > > --Sri > > > > On 27 April 2010 07:08, John V Denley <[email protected]> wrote: > >> Ive just created an application as part of a learning experience about >> security with GWT/GAE >> >> This has prooved necessary after discovering that using google account >> logins is unacceptably complex for our potential clients, and as there >> are no plans within google for a tighter integration with GWT/GAE I >> have had to do it myself. >> >> I know that I am not using SSL/HTTPS and that probably means im very >> vulnerable to man in the middle (eve) attacks? but I dont know how to >> test exactly HOW easy it is to crack, or if its even anything i reall >> need to worry about! >> >> www.ucanzoom.appspot.com >> >> Happy to hear any feedback >> >> Thanks, >> John >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Google Web Toolkit" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]<google-web-toolkit%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/google-web-toolkit?hl=en. >> >> > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<google-web-toolkit%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
