Typically, or at least in my experience, salting is md5/sha1/whatever(password+salt) rather than md5(md5(password)+salt) ...
Thanks- - Andy Badera - [email protected] - (518) 641-1280 - Tech Valley Code Camp 2009.1: http://www.techvalleycodecamp.com/ - Google me: http://www.google.com/search?q=andrew+badera On Fri, Jan 23, 2009 at 4:01 PM, Greg <[email protected]> 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 at http://code.google.com/p/gmemsess/ > > Cheers! > Greg. > > On Jan 24, 8:42 am, MajorProgamming <[email protected]> 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 [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-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
