cookies

[brown2005]

	if(isset($_COOKIE['ID_my_site']))
{ 

	echo"yes there is a cookie";

}else{
  
	$hour = time() + 3600; 

	$username = "rberbe2002";
	$password = "charliew";

	setcookie(ID_my_site, $username, $hour); 

	setcookie(Key_my_site, $password, $hour);

}

 

I am trying to create a loging script. I want this to be as secure as possible. I am trying to see if implementing cookies will work, but obviously the cookie set if someone could get this off my comp they could see my username and password. how can i make this more secure? and is there anyway to encrypt a cookie so it cant be read

[MartinGr]

You could encrypt the password using md5().

[PFMaBiSmAd]

The cookies you use to identify a visitor should not use any direct identifying information, such as a username or password. You should also not store a fixed/static value, such as the md5 of a password as that would prevent you from regularly regenerating a new value to guard against the cookie being hijacked and allowing someone to impersonate the actual user.

 

What you should do is generate a unique id (see this function - uniqid) that is then stored in the cookie and stored in your user table for that visitor. The unique id is then used to associate the visitor with his record in the user table. You can then regenerate this unique id, updating the cookie value and the value in the user table, as needed (some people regenerate it on every page visit) to help guard against someone impersonating the actual visitor if they get a hold of the value in the cookie.

[brown2005]

hi, thanks for the info, but say someone hacked my comp and read the cookie for the website, and then set the same cookie on there computer, would this not let them log on to the site with the id in the table.

 

 

[PFMaBiSmAd]

Yes, but that is true of any method you use that relies on a value in a cookie to identify a visitor.

 

The unique identifier method at least would only allow access on your site (people often use the same username and password everywhere.) By regenerating the unique id while the original visitor is active on your site, you limit the time frame where any stolen unique id can be used by someone else.

 

For any operation that requires more security, such as changing the password or the email address associated with a visitor, you would not just rely on someone having a cookie that identifies them, you would require that they re-enter the username and password to re-authenticate who they are.

 

You also need to store the logged in/logged out status in the user table so that when someone manually logs out or is automatically logged out a time after their last activity on your site, the only way they can log in is by providing the correct username and password. Just having a cookie with the correct value in it should not be enough to indicate that someone is logged in. The cookie should only serve to identify who they are.

[brown2005]

so basically say add a

 

member_login (datetime)

 

in the table and then when they log out say delete this as well as the cookie..

[PFMaBiSmAd]

as well as the cookie..

Deleting a cookie is pointless and a waste of bandwidth and processing time. Also, you cannot delete a cookie unless the visitor is actively making requests for your web pages.

[brown2005]

ok so leave the cookie on the computer.

 

just update it all the time.. and when you log out just take the logout time from the table so it doesnt allow someone to log in, till they enter the username and password.

 

 

[MartinGr]

just update it all the time.. and when you log out just take the logout time from the table so it doesnt allow someone to log in, till they enter the username and password.

In that case, why not to use sessions instead of cookies?

[PFMaBiSmAd]

Using a cookie (long term - remember me) or a session (short term - one browser session) to identify the visitor both have the same security issues and solutions mentioned in this thread. And in fact, the unique id suggested for the cookie value is essentially what a session id does.