Forum Moderators: coopster
- Users enter username/pass
- This data is sent over https to a verification page
- Verification page checks the details
- If the details are correct a new session is created
- The session key is added to the database and the user gets a copy as a cookie
- All pages requiring account only access check the cookie key against the DB key
- When the user logs out or the account is left idle the session key in the DB is deleted
Is there any room for improvement here or is that sufficient. I have stored IP's in the past but as a lot of peoples IP's can be switched by there ISP's during a session this isn't practical.
My main concern is really that having a single cookie may not be very secure and it would be easy to generate random cookies until a match is found. The keys are md5 hashes so this would be unlikely but still possible.
Would using two cookies be worthwhile or maybe some other approach?
I know people may prefer PHP sessions but these are stills stored as cookies.
I can't see any benefit to using URL or header passed variables either as these could be easily manipulated as well.
I'm looking for the most secure method possible.
Thanks
You could have shorter keep alive times too
I tend to take some data that i have about a user that doesn't change and hash that up to provide a key, then i can compare that on each request.
always keep in mind that the more checks you add the more your users may have to relogin. This is accepted but deciding wher the invasive threshold is can be difficult.
user agent data is pretty good
geoip is something too, users seldom switch countries, though this requires some processing
though they switch ips, ip can be partially used, same ip as previous request is a positive, a changed ip is not a negative.
anything else you can find is good, i hate reying on a single piece of data, i like to start with two, plus if it is that sensitive then making users login a bit more is no big thing.
[us3.php.net...]
fast expiries also help keep this window small
the cookie is client side so there is no way for us to protect it