clancy_1@xxxxxxxxxxxx wrote: > On Thu, 21 Jan 2010 22:00:30 +0000, ash@xxxxxxxxxxxxxxxxxxxx (Ashley Sheridan) wrote: > >> On Fri, 2010-01-22 at 08:58 +1100, clancy_1@xxxxxxxxxxxx wrote: >> >>> On Thu, 21 Jan 2010 08:54:44 -0500, tedd.sperling@xxxxxxxxx (tedd) wrote: >>> >>>> At 12:15 PM +1100 1/21/10, clancy_1@xxxxxxxxxxxx wrote: >>>>> On Wed, 20 Jan 2010 20:05:42 -0200, bsfajardo@xxxxxxxxx (Bruno Fajardo) wrote: >>>>> >>>>> >Well, I hope this information is helpful. >>>>> >>>>> Yes, thanks to everyone who contributed. I now have a better >>>>> understanding of what >>>>> cookies are, and have turned on output buffering, enabling me to put >>>>> the handler where I >>>>> want, and still be able to debug it. >>>>> >>>>> Clancy >>>> One last thing. >>>> >>>> I use sessions for the storage of variables I need between pages, but >>>> I use cookies to leave data on the user's computer in case they come >>>> back to my site and want to pick up where they left off. >>>> >>>> Both operations store variables, but are for different purposes. >>> Yes; I'm doing that too. I am setting up a private website, and using cookies to control >>> access to it. >>> >>> Clancy >>> >> >> Don't use cookies, use sessions for this. Information stored in cookies >> is susceptible to being read by pretty much anyone, hence the scare of >> using cookies that people get. Cookies in themselves are not the >> problem, but using them for anything you want to keep safe, like login >> details, etc, is a bad idea. Generally, a session ID is stored in the >> cookie, which gives nothing away to anyone trying to read it. > > Thank you all for your comments. > > My reasoning in using a cookie for user recognition, rather than relying on the session > ID, was that with a cookie I could ensure that the connection effectively lasted for some > specified period, whereas the session ID lifetime seems to be somewhat short and > ill-defined. In this way I can be sure that the user will not be logged out unexpectedly. > The actual value of the cookie I use is an MD5 hash of some user information with an > additional random component, so that it would be extremely difficult to extract anything > useful from it. It could equally be a random number, as it is verified by matching with a > value stored on the server. I am also considering changing it every so often (every > hour?) while the user is logged in, so that an old value would be useless to a hacker. > > At present I am using a normal text window for the user to log in, and I suspect that this > is by far the weakest link in the system. The website is relatively obscure, and there is > nothing particularly valuable on it, but I would be grateful for any suggestions how I > could make this procedure more secure. > > session_id's are (normally) saved in the cookie; and serve as a key to identify a user; so you store all your session based data for a user (such as the fact they are logged in) server side; then assign that info a key; then give that key to the users client so you can recognise them; this *is* what sessions do, session_id is that key, done automatically, via a cookie - to replicate this functionality with your own version is frankly a waste of time. It appears the problem here is that your sessions are timing out too quickly, two simple approaches would be to boost the session lifetime to last longer OR create a quick (ajax) request every X minutes to keep the user logged in when inactive (which they may not want). To answer your specific questions though - what can be done to make this process more secure - no matter what approach you take, when working via http and needing logged in / secure functionality; you need the client to identify themselves with a key of some sort - no matter how you make the key it's always going to be passed via http (GET/POST/COOKIE) - if some "hacker" passes the same key then your system is going to think it's the original user and give them access. To make it trickier you can store information such as the users IP address, user agent string etc in session and compare it on each request; if it changes log the user out and destroy the session data - however your never going to protect against the most common form of "hacking", a nosy co-worker / person in the same house having a nosey while the user is at the toilet / making a brew. This is why many sites re-request password confirmation for potentially sensitive actions like transferring money, changing personal details and so forth (and send email confirmations to tell the user what changed - just in case). It must be pointed out though that non of this is worth even considering if you have sensitive ports (like ftp/ssh/mysql) open to the outside world as it's these back doors people will use to hack the whole server, not just one users personal account on a single site. Also protect against SQL injection attacks by sanitizing your data and so forth. Finally, view it as your responsibility to never store anything personal or identifying (or in fact anything) on the client side in a cookie - one simple key (session_id) in the cookie and everything on the safe secure server is the way to go. Regards! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
