Problems with sessions

[Grenz]

Hi all
I have a site with this basic function:
1: user fill out form
2: users get a random generated password sent to their mail
3: users login with their password and username
4: user can if they want - change the password
5: users log out

All of this is done in php and works fine. The problem arises when they log out and then want to login again. Its like the logout function ruins the password. How - i dont know

I dont have a clue about what is wrong. Do any of you have suggestions of possible errors or just where to start looking?

Thanks a lot

[blang]

Can you define "ruins the password"? Is this after the initial registration & login, or after they reset their password? What facility are you using to store the user data? Are you checking the data after the initial registration? Is it being changed in any way?

[Grenz]

Sorry - I cant define "ruins the password" cus I dont know what is wrong.
The problem with login occur after the logout. Both if you dont change the password - and if you do.

The pasword is stored in a mySQL database. The password is however encrypted in the database so I cant look up the exact password.
But I can see that the password is stored in the database after the initial registration. And it is also possible to login once.

My only guess the logout function. It is:

<?php
unset($_SESSION['company_profile_id'], $_SESSION['company_profile_name']);
header("Location: /");
?>

But aint it a very normal one?

Thanks in advance

[blang]

Well, yes. All that is doing is unsetting the session data, which has nothing to do with the data stored in the db.

Can I assume you've gone step by step as a new registered user, checking the data stored as you go? In other words, perform the registration, and do a query on the database for the new login data. Once you can verify the login data, logout and see if anything in the database changes from the initial login.

Another thought; you mentioned the password is 'encrypted', are you referring to a one-way hash such as MD5 or SHA1? If so, are you checking the hashed password in the login against the value stored in the database? In other words, after you store the hash, you make sure to re-hash the login data to compare it against?

In keeping with that line of thought, have you bothered to take a string, run the same hash algorithm against it, and compare it to what is stored in the database `password` field?

One last thought related to the password; what column data type / length did you use? Be sure the hashed password string isn't being truncated because the field is too short.

[Grenz]

Hi
Thanks for all the suggestions. The later three parts where very usefull. Im trying them out now.
I may return if it doesnt solve the problem.

Thanks a lot :-)

[blang]

Sure. Something I neglected to mention before (RE: field length), an MD5 hash is a fixed 32 characters, an SHA1 hash is a fixed 40 characters, SHA256 is 64, etc etc. So be sure to use a proper fixed length field, like CHAR(32) or CHAR(40) for that field. This is a very common newbie mistake, as a field that is too short is often used and the password hash value is truncated and of course you can never login.

If I've made the wrong assumption and you're using some other method to store the password, e.g. MySQL's PASSWORD function or PHP's crypt() function, then you should strongly reconsider and use a better hash method such as SHA256. My personal feeling, most applications are just fine with SHA1 and a salt, especially because SHA1 is so portable - it's just available across so many languages. MySQL has a built in SHA1 function, and there are some good JavaScript implementations as well.

[henry0]

As per blang I will follow the steps method
and add an exit() and an echo before the PW is written to the DB
Then I will check if the PW inserted as the same value

you may also create (just for test purposes) a mini script to echo any md5(PW)
and again check if what you got is what is expected
error often occurs from double md5()

[Grenz]

Hi
Now the random generated password is no longer encrypted before its inserted into the database. That helped so the user can log in and out and in again, with the random password.

However - if the user tries to change the password it is still encrypted.
I had a friend to help me with the code cus im still very new to PHP so I cant figure out the problem.

Here is the code:

This code is a part of the "change password form"

<?php
if($_POST["password1"] == $_POST["password2"]){
//print_r($_SESSION);
//echo $_SESSION["name"]."<br>".$_POST["password1"];
$password_enc = Utils::encrypt($_SESSION['name'],$_POST['password1']);
$data = array(
'password' => "'".$password_enc."'"
);
$db = $GLOBALS["db"];
$n = $db->query('UPDATE company_profile SET password = ? WHERE id = ?', array($password_enc, $_SESSION["company_profile_id"]));
echo "Password updated";
} else {
echo "password mismatch";
}
?>

The "Utils::encrypt" comes from this code:

public static function encrypt($username,$password){
$salt = self::generateSalt($username);
$encrypted = base64_encode(sha1($salt.$password,true));
return $encrypted;
}

private static function generateSalt($username){
$step = floor(strlen($username) / 2 + 1);
$username = md5($username);
$i = 0;
$salt = "";
while(strlen($salt) < 10){
$salt .= $username{$i};
$i = ($i + $step) % strlen($username);
}
return $salt;
}

The field for the password in the mySQL database is a varchar(255) so there should be plenty of space.

There is no change in the database when the user log in and out (ive checked) so as far as I can see - it must be the Utils::encrypt function that messes things up.

You said:
"Another thought; you mentioned the password is 'encrypted', are you referring to a one-way hash such as MD5 or SHA1? If so, are you checking the hashed password in the login against the value stored in the database? In other words, after you store the hash, you make sure to re-hash the login data to compare it against?"

I dont really get this part. How do you re-hash?

Sorry if I sound very stupid but I think this is somewhat more difficult than I assumed.
Normally I can do what I need in PHP but its far from my strongest side :-)

[blang]

Your Utils::encrypt method is using a one-way hash, SHA1, to hash the password, adding a random salt to it on the way. BUT it's also using base_64_encode (why is this necessary?) to further complicate things. So the output string is actually base64 encoded. NOT strictly an SHA1 hash value. The other thing to take into consideration is the salt that is being stored within the hash value, which must take place each time and also on the 'login check'.

So in order to log a user in, you need to reproduce this process in part, by 're-hashing' the plain password value the user inputs.

[Grenz]

Just to cut it out:

Basically I need the same encryption to take place when the user enters the password, so before its matched with the value in the DB it is "converted"
Is that right?

[blang]

Exactly. Otherwise you're trying to compare a string like 'myPassword1' with the base64 encoded value 'YzI0N2RlZDhjYThhNTkwNWYzODIyNDcwZTk0MGMwMDhjYTBiYTU0Zg=='. You have to perform the same hash method that you used to originally store the password, and compare the result from that method with the stored value.

[Grenz]

Hi Blang
Thanks a lot for your help.
I must admit I had my friend to help me with adding the encryption to the login function - but it worked perfectly afterwards.

When someone like you explain the error and it works it really seems so obvious. I was ready to give up entirely.

Thanks a lot!

[blang]

NP. Glad you got it sorted out.