[google-appengine] Re: Custom Login System
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 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 -~--~~~~--~~--~--~---
[google-appengine] Re: Custom Login System
Typically, or at least in my experience, salting is md5/sha1/whatever(password+salt) rather than md5(md5(password)+salt) ... Thanks- - Andy Badera - and...@badera.us - (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 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 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 -~--~~~~--~~--~--~---
[google-appengine] Re: Custom Login System
"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 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 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 -~--~~~~--~~--~--~---
[google-appengine] Re: Custom Login System
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 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 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 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
[google-appengine] Re: Custom Login System
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" 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 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 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 fr
[google-appengine] Re: Custom Login System
On Jan 24, 10:10 am, Andrew Badera wrote: > Typically, or at least in my experience, salting is > md5/sha1/whatever(password+salt) rather than md5(md5(password)+salt) ... If you just hash the password plus the salt, you need to store the password on the server. This is bad, both because servers are vulnerable and also because at some stage you have to transmit the password in clear. So you transmit (and store) the hash of the password, which means you need to hash it twice when you login. > But can't the attackers simply spoof a request with that session id in > the cookies? Yes, but only while the session is valid. At the very least make your sessions expire frequently, and make logging out enticing for users. And you could also make their IP address part of the salt, and have the server check it. This limits attacks to your internal network. Cheers! Greg. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[google-appengine] Re: Custom Login System
"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" 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" > > 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 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 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 visib
[google-appengine] Re: Custom Login System
Hmm. So basically this would sum it up:? 1. If I use SSL, I can rely on the cookies? 2. If I don't use SSL and use another provider for the password check (like OpenID, etc.), I need to take your advice on Sessions expiring? Am I correct? And, what are the real chances of a hacker intercepting traffic? On Jan 24, 6:41 pm, Greg wrote: > On Jan 24, 10:10 am, Andrew Badera wrote: > > > Typically, or at least in my experience, salting is > > md5/sha1/whatever(password+salt) rather than md5(md5(password)+salt) ... > > If you just hash the password plus the salt, you need to store the > password on the server. This is bad, both because servers are > vulnerable and also because at some stage you have to transmit the > password in clear. So you transmit (and store) the hash of the > password, which means you need to hash it twice when you login. > > > But can't the attackers simply spoof a request with that session id in > > the cookies? > > Yes, but only while the session is valid. At the very least make your > sessions expire frequently, and make logging out enticing for users. > And you could also make their IP address part of the salt, and have > the server check it. This limits attacks to your internal network. > > Cheers! > Greg. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[google-appengine] Re: Custom Login System
Real informative post for a beginner like me. The post title suits me completely. I need to make a basic user management system for my app. I have been googling the possibility of using django admin interface with GAE but the django-appengine-helper and django-patch look hackish to me. I dont really want them to be. At the same time I wanted to find something readymade (being lazy, that I am). Both the session handlers above, gaeutils and gmemsess provide me with a good start. Is there any simple user registration or login framework that I can use. Ofcourse when I am here, I dont want my users to have a google acocunt. Thanks again for you post and work. Cheers Varun On Jan 25, 6:35 am, MajorProgamming wrote: > Hmm. So basically this would sum it up:? > > 1. If I use SSL, I can rely on the cookies? > > 2. If I don't use SSL and use another provider for the password check > (like OpenID, etc.), I need to take your advice on Sessions expiring? > > Am I correct? > > And, what are the real chances of a hacker intercepting traffic? > > On Jan 24, 6:41 pm, Greg wrote: > > > > > On Jan 24, 10:10 am, Andrew Badera wrote: > > > > Typically, or at least in my experience, salting is > > > md5/sha1/whatever(password+salt) rather than md5(md5(password)+salt) ... > > > If you just hash the password plus the salt, you need to store the > > password on the server. This is bad, both because servers are > > vulnerable and also because at some stage you have to transmit the > > password in clear. So you transmit (and store) the hash of the > > password, which means you need to hash it twice when you login. > > > > But can't the attackers simply spoof a request with that session id in > > > the cookies? > > > Yes, but only while the session is valid. At the very least make your > > sessions expire frequently, and make logging out enticing for users. > > And you could also make their IP address part of the salt, and have > > the server check it. This limits attacks to your internal network. > > > Cheers! > > Greg.- Hide quoted text - > > - Show quoted text - --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[google-appengine] Re: Custom Login System
Not so much sessions expiring, as short lived session tokens. In gaeutilities case by default each session token is good for about 15 seconds. The risk is someone sniffing the traffic, adding the session token as a cookie, making their user agent match yours, and coming from the same IP. Eventually (within a minute of page refreshes) the session tokens between the valid browser and the hack browser will differ and one of them would have complete control of the session. The best thing to do in this case would be to tie the session to the account. That way if the valid user gets knocked off, they can log back in and sieze control of their account. Now this really is not fool proof in any way. 15 seconds is a long time when it comes to being able to sniff and duplicate a cookie and user agent. IP can be managed by being on the same network ( ie: same Starbucks ). Once an attacker has access to a session, they can reset the password so the user can't log back in to seize the session. Yahoo! way back when, (not sure about now) would lock an account after several failed attempts to log in, in order to help with this kind of attack. SSL really is the best option, if possible, for managing sessions. Everything I've done is more of a best attempt possible to make it a bit work to steal the session, and everything above that would need to be handled by the application developer as there is no user management built in. The problem is HTTP is such an anonymous protocol there really is not way to uniquely identify a visitor. Before anyone suggests it, MAC addresses are extremely easy to spoof too. On Jan 24, 8:35 pm, MajorProgamming wrote: > Hmm. So basically this would sum it up:? > > 1. If I use SSL, I can rely on the cookies? > > 2. If I don't use SSL and use another provider for the password check > (like OpenID, etc.), I need to take your advice on Sessions expiring? > > Am I correct? > > And, what are the real chances of a hacker intercepting traffic? > > On Jan 24, 6:41 pm, Greg wrote: > > > On Jan 24, 10:10 am, Andrew Badera wrote: > > > > Typically, or at least in my experience, salting is > > > md5/sha1/whatever(password+salt) rather than md5(md5(password)+salt) ... > > > If you just hash the password plus the salt, you need to store the > > password on the server. This is bad, both because servers are > > vulnerable and also because at some stage you have to transmit the > > password in clear. So you transmit (and store) the hash of the > > password, which means you need to hash it twice when you login. > > > > But can't the attackers simply spoof a request with that session id in > > > the cookies? > > > Yes, but only while the session is valid. At the very least make your > > sessions expire frequently, and make logging out enticing for users. > > And you could also make their IP address part of the salt, and have > > the server check it. This limits attacks to your internal network. > > > Cheers! > > Greg. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[google-appengine] Re: Custom Login System
As a suggestion, the app-engine-patch project is a very nice product. I'm personally using it, on substituting gaeutiltiies sessions and cache, with very good results on my primary project. Being able to take advantage of Django's backends had me authenticating accoutns through Google (OpenID) and Yahoo(Oauth with their persistent id field) literally in minutes. And I see nothing stopping me from adding Myspace and Facebook when I'm ready. On Jan 30, 10:05 am, varun wrote: > Real informative post for a beginner like me. The post title suits me > completely. I need to make a basic user management system for my app. > I have been googling the possibility of using django admin interface > with GAE but the django-appengine-helper and django-patch look hackish > to me. I dont really want them to be. At the same time I wanted to > find something readymade (being lazy, that I am). Both the session > handlers above, gaeutils and gmemsess provide me with a good start. > Is there any simple user registration or login framework that I can > use. Ofcourse when I am here, I dont want my users to have a google > acocunt. > > Thanks again for you post and work. > > Cheers > Varun > > On Jan 25, 6:35 am, MajorProgamming wrote: > > > Hmm. So basically this would sum it up:? > > > 1. If I use SSL, I can rely on the cookies? > > > 2. If I don't use SSL and use another provider for the password check > > (like OpenID, etc.), I need to take your advice on Sessions expiring? > > > Am I correct? > > > And, what are the real chances of a hacker intercepting traffic? > > > On Jan 24, 6:41 pm, Greg wrote: > > > > On Jan 24, 10:10 am, Andrew Badera wrote: > > > > > Typically, or at least in my experience, salting is > > > > md5/sha1/whatever(password+salt) rather than md5(md5(password)+salt) ... > > > > If you just hash the password plus the salt, you need to store the > > > password on the server. This is bad, both because servers are > > > vulnerable and also because at some stage you have to transmit the > > > password in clear. So you transmit (and store) the hash of the > > > password, which means you need to hash it twice when you login. > > > > > But can't the attackers simply spoof a request with that session id in > > > > the cookies? > > > > Yes, but only while the session is valid. At the very least make your > > > sessions expire frequently, and make logging out enticing for users. > > > And you could also make their IP address part of the salt, and have > > > the server check it. This limits attacks to your internal network. > > > > Cheers! > > > Greg.- Hide quoted text - > > > - Show quoted text - --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
