Sign in to follow this  
Thoover

[web] php user/pass storing cookie??

Recommended Posts

i am trying to make a login page to store the user and pass for all the other pages, so far my code is: and its not working at all...
<?PHP
$place=$_GET['place'];
$usernam=$_POST['usn'];
$passwor=$_POST['pwd'];
$host = "*";
$user = "*";
$pass = "*";
mysql_connect($host, $user, $pass) or die(mysql_error());
mysql_select_db($user) or die(mysql_error());
$result = mysql_query("SELECT * FROM users") or die(mysql_error());  
$corr="[0]";
while($row = mysql_fetch_array($result)){
	$dpwd=$row['pass'];
	$dusr=$row['user'];
	if($dusr == $usernam)
	{
		if($dpwd == $passwor)
		{
			$corr = $row['type'];
		}
	}
}
if($corr=="[0]"){echo '<script type="text/javascript">window.location = "**[1]'.$place.'"</script>';}
if($corr=="[1]"){
setcookie("signedas", $usernam); 
setcookie("signedpass", $passwor); 
if($place == "home")
	echo '<script type="text/javascript">window.location = "**[2]"</script>';
else
	echo '<script type="text/javascript">window.location = "**[2]'.$place.'"</script>';
}
if($corr=="[2]"){
setcookie("signedas", $usernam); 
setcookie("signedpass", $passwor); 
if($place == "home")
	echo '<script type="text/javascript">window.location = "**[2]"</script>';
else
	echo '<script type="text/javascript">window.location = "**[2]'.$place.'"</script>';
}
if($corr=="[3]"){
setcookie("signedas", $usernam); 
setcookie("signedpass", $passwor); 
if($place == "home")
	echo '<script type="text/javascript">window.location = "**[2]"</script>';
else
	echo '<script type="text/javascript">window.location = "**[2]'.$place.'"</script>';
}
?>

this 1 dosnt store safely nor at all keeps going to **1 never (even with right user/pass) to **2 any better suggestions?

Share this post


Link to post
Share on other sites
Several comments on your system:

1) Never store the user's password in the database. If the database is stolen then the thief has all of your users' passwords

2) Never store the user's password in a cookie. Gamedev did that once. One member then wrote a program called "FongerChat" which pretended to be a chat client but also read the user's GDNet cookie and sent the password to the program's author. The result was that several user's accounts were compromised. Dont let this happen to you.

3) In fact, never store the user's password anywhere. Even storing an MD5 hash of the plaintext password is no longer enough. It's much safer to store a salted hash of the password. This can be done by generating a random string, appending it to the password, then storing the MD5 or SHA-1 (or whatever other one-way hash algorithm you use) hash of that in the database.

To check if the user has submitted the correct password, regenerate that hash and compare to what you have stored in the database.

Share this post


Link to post
Share on other sites
Quote:
Original post by Colin Jeanne
Several comments on your system:

1) Never store the user's password in the database. If the database is stolen then the thief has all of your users' passwords

2) Never store the user's password in a cookie. Gamedev did that once. One member then wrote a program called "FongerChat" which pretended to be a chat client but also read the user's GDNet cookie and sent the password to the program's author. The result was that several user's accounts were compromised. Dont let this happen to you.

3) In fact, never store the user's password anywhere. Even storing an MD5 hash of the plaintext password is no longer enough. It's much safer to store a salted hash of the password. This can be done by generating a random string, appending it to the password, then storing the MD5 or SHA-1 (or whatever other one-way hash algorithm you use) hash of that in the database.

To check if the user has submitted the correct password, regenerate that hash and compare to what you have stored in the database.


ok first of all who would want GDNet usernames, there is no point to that

second you got more info on this salted passwords, for one i dont trust wikipedia plus it dosnt really explain how to do that.


and about sessions that helps, but the code still sais that $corr = "0" (any idea on this (and yes type is not 0 on the users))

Share this post


Link to post
Share on other sites
heck since this is all over https how secure would it be to just use post on every page to send this info around if i encrypt it by using javascript? even though if you left this on your computer screen anyone can look in source and find the encrypted version and decrypt it

Share this post


Link to post
Share on other sites
Salting a password is simply adding a text string to it before you hash it. To check a password to see if it's correct you need to add the same string to the password and hash it and compare the two hashes.

It would help to have more information about your database although there are a few glaring problems before we even get that far. You should be doing the username/password check in SQL. Something along the lines of...


SELECT
type
FROM
users
WHERE
usn = $usernam AND
pwd = $pass;



Are you really storing the type in the database as [1], [2] and [3]? You should look into using something a bit more descriptive.

Share this post


Link to post
Share on other sites
Quote:
Original post by Thoover
heck since this is all over https how secure would it be to just use post on every page to send this info around if i encrypt it by using javascript? even though if you left this on your computer screen anyone can look in source and find the encrypted version and decrypt it


There is no such thing as encrypting is using javascript. Well there is, but it's thoroughly useless and not in any way secure.

Share this post


Link to post
Share on other sites
The Wikipedia article is fairly complete and accurate. There isnt much reason not to trust it. In any case, I have found this blog post which explains what salting is, why you should use it, and provides PHP examples of it.

For password recovery should never be about telling the user what their password is. This is too dangerous because if your system fails then you could inadvertently tell someone pretending to be the user that user's password. Since most users use the same password in multiple places you will have compromised their accounts at each of these locations.

Instead password recovery is about generating a new password temporarily. There are a few ways to implement this:

1. The easy, but not incredibly secure way, is to generate a new password for that user, store its salted and hashed form in the database, and email the password to the user. The danger here is that now the user has an email with their password in cleartext. Hopefully, however, they will change their password quickly. You can help mitigate this by requiring that the user change their password immediately after logging in after using this generated password.

2. A bit more difficult way is to never send the cleartext password and to never even generate one. When the user does password recovery you generate a special URL that that user can go to to create a new password for themselves. This URL should be relatively short-lived and it's probably best if your system never generates the same URL twice.

Both of these systems can include a confirmation email that is sent to the registered email address before starting the password recovery process. You'd send a short-lived URL to the user which they can go to to verify that they do want the process to start. This can help prevent people from attempting a poor-man's DoS against an account by repeatedly requesting a password recovery and thereby causing the password to always change.

Another way to help prevent this type of DoS is to use a password recovery question. Before allowing a password recovery to continue the user must answer a password recovery question correctly. To provide this system, allow the user to specify one (or preferably more) questions and their answers. The user should be able to create their own questions and write their own answers rather than selecting from a list of prechosen questions. When doing the recovery present the user with a randomly selected question.

When doing this, be sure it accept the answer in slightly varied ways. That is, punctuation and capitalization probably shouldnt matter in deciding if the answer is correct.

Share this post


Link to post
Share on other sites
ok new problem my code cut:

<?PHP
session.auto_start;
session_start();
.........
$_SESSION['user'] = $usernam;
$_SESSION['pass'] = $passwor;
session_register();
setcookie("sessionid", session_id());

echo '

session id='.session_id();
echo '
cookie='.$_COOKIE['sessionid'];
}
?>

i get the session id when just looking it up, but i cant find out why it is not storing the cookie can anyone find my problem here?

Share this post


Link to post
Share on other sites
problem with index page now the php code:

<?php
if(isset($_COOKIE["sessionid"])){
session_id($_COOKIE['sessionid']);
echo 'Hello '.$_SESSION[user].'
Sign Out';
}
if(!isset($_COOKIE["sessionid"])){
echo 'Sign In';
}
?>

it dosn't say that the cookie is set here how do i make a cookie work for the whole URL not just one page?

Share this post


Link to post
Share on other sites
$_COOKIE is a copy of the cookie values sent back by the user. Modifying this copy will not change the cookies on the user side. Cookies on the user side must be created and modified using setcookie.

Share this post


Link to post
Share on other sites
PHP's session handling mechanism will already store the session ID in the cookie. When using PHP to manage sessions you can forget that the cookie exists entirely. You also do not need to use session_register(). If you want to set a session variable just use the $_SESSION array.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this