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 <[email protected]> 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 <[email protected]> wrote: > > > On Jan 24, 10:10 am, Andrew Badera <[email protected]> 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 [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 -~----------~----~----~----~------~----~------~--~---
