Jump to content

Validating/signing in with password singed up with after sha1 hash/salt


Recommended Posts

why don't you try and:

$query = "SELECT * FROM `cysticUsers` WHERE `Email` = '$email' AND Status = 'active' LIMIT 1";
$request = mysql_query($query,$connection) or die(mysql_error());
if(mysql_num_rows($request))
{
while($row = mysql_fetch_array($request)) {
$salt_pass = sha1($row['salt'].$_POST['password']);
$_POST['password'] = $_POST['password'].$salt_pass;
...
...
...

 

Then validate if its not the correct email or password and redirect them to a location. Tho, the last bit of code may be wrong (think it's missing something):

$_POST['password'] = $_POST['password'].$salt_pass;

@Skylight_lady -  seems worth a try :) although not sure what you are referring to with the

...

...

...

 

after your reworked query are you saying I should do something like:

 

if($_POST['password'] = $_POST['password'].$salt_pass; ) { validate sign in}else{ no go }

Do you have error_reporting set to E_ALL (or a -1) and display_errors set to ON so that all the php detected errors are being reported and displayed? That would help answer what is going on and if there are mis-matches between your variable/index names.

 

Don't put any @ in front of your statements to suppress errors. That just hides the problems. Your code still won't work but you won't have any idea where to look to find the problem.

 

Do you know for a fact that your query is being executed and it is not producing an error? For all we know, your login form isn't submitting values in $_POST['subSignIn'], $_POST['email'], and $_POST['password'] and the code is being completely skipped over.

 

I recommend troubleshooting what your code and data are actually doing. What is the current  code and is it the only code on the page or is it combined with the other operations?

I know for a fact _POST['subSignIn'], $_POST['email'], and $_POST['password'] are working. I have been logging in with this page for a year, and now that I've altered the script to interact with the newly hashed passwords has it stopped working. I just think there is something off about the queries I am trying.

 

yes the errors are turned on. not getting any for my existing code, when I do its just syntax errors.

See my comments in your code:

/* You are only selecting "id" here, so the other fields are not available
   Also, you are comparing the database (hashed) password against a hash of the (clear text) password
   so if you get ANY rows at all, then the user is validated */
$query = "SELECT `id` FROM `cysticUsers` WHERE `Email` = '$email' AND `Password` = 'SHA1(CONCAT(`salt`,'$password'))' AND Status = 'active' LIMIT 1";
$request = mysql_query($query,$connection) or die(mysql_error());

/* Take out the "@" - it may be hiding errors. Don't use @ to hide errors, let
   the errors show IN DEVELOPMENT and fix them */
if(@mysql_num_rows($request)) {
/* The only thing that will be in $row now, is "id", that is ALL that you selected
   if you want more data, add it to the SELECT statement  */
$row = mysql_fetch_assoc($request);

/* You have already done this comparison in the SELECT statement. If you
   get here, then the user has been validated - this IF is NOT needed
   
   Also, you did NOT select "salt" or "Password" so those elements are NOT
   in the $row array, you should be getting error (warning) messages here if
   you have error reporting turned on.  */
if (sha1($row['salt'] . $_POST['password']) === $row['Password']) {

	/* Indent your code consistently, so you can see what is supposed to happen */
	$_SESSION['CLIFE']['AUTH'] = true;
	$_SESSION['CLIFE']['ID'] = $result['id'];

	// UPDATE LAST ACTIVITY FOR USER
	$query = "UPDATE `cysticUsers` SET `LastActivity` = '" . date("Y-m-d") . " " . date("g:i:s") . "' WHERE `id` = '" . mysql_real_escape_string($_SESSION['CLIFE']['ID']) . "' LIMIT 1";
	mysql_query($query,$connection);

	if(!empty($_POST['return'])) {
		header("Location: " . $_POST['return']);
		/* ALWAYS put an exit() statement immediately after a header() redirect.
		   otherwise, the script will continue to execute until the browser 
		   acts on the redirect  */

	}else{
		header("Location: CysticLife-Dashboard.php?id=" . $_SESSION['CLIFE']['ID']);
		/* ALWAYS put an exit() statement immediately after a header() redirect.*/
	}
}

}else{

$_SESSION['CLIFE']['AUTH'] = false;
$_SESSION['CLIFE']['ID'] = false;

}
}

 

Note: I did NOT make any changes to your code except to add comments about what you need to change. If you copy & paste this code, it will NOT behave any differently.

now that I've altered the script to interact with the newly hashed passwords has it stopped working

 

You are storing the newly registered hashed passwords in a column named Password, however you UPDATED the pre-existing passwords and saved them into a column named encrypted_passwords

 

What exactly does not work? Logging in with an account that pre-existed or a newly created one, because where you have the hashed passwords stored is currently different, based on what you have posted so far.

 

^^^^ This is why I suggested in my last post that you need to troubleshoot WHAT your code and data are actually doing.

ok guys. I've considered and taken from everything you have said and started over,although I still don't have it. I think this is way closer and makes much more sense.

 

 

 

$salty_password = sha1($row['salt'], $_POST['password']);

if(isset($_POST['subSignIn']) && !empty($_POST['email']) && !empty($_POST['password'])) {


$query =  "SELECT `salt` FROM `cysticUsers` WHERE `Email` = '" . $_POST['email'] . "'";
$request = mysql_query($query,$connection) or die(mysql_error());
$result = mysql_fetch_array($request);



$query2 = "SELECT * FROM `cysticUsers` WHERE `Email` = '". $_POST['email']."' AND `Password` = '$salty_password'";
$request2 = mysql_query($query2,$connection) or die(mysql_error());
$result = mysql_fetch_array($request2);

print_r($request);
print_r($request2);

if(@mysql_num_rows($request,$request2)) {


	$_SESSION['CLIFE']['AUTH'] = true;
	$_SESSION['CLIFE']['ID'] = $result['id'];

	// UPDATE LAST ACTIVITY FOR USER
	$query = "UPDATE `cysticUsers` SET `LastActivity` = '" . date("Y-m-d") . " " . date("g:i:s") . "' WHERE `id` = '" . mysql_real_escape_string($_SESSION['CLIFE']['ID']) . "' LIMIT 1";
	mysql_query($query,$connection);


	if(!empty($_POST['return'])) {
		header("Location: " . $_POST['return']);

	}else{
		header("Location: CysticLife-Dashboard.php?id=" . $_SESSION['CLIFE']['ID']);
		}
	}

}else{

	$_SESSION['CLIFE']['AUTH'] = false;
	$_SESSION['CLIFE']['ID'] = false;

}

Sorry if I sound stupid, but due to the random nature of the hashing process, won't your $salt change each time it is called.

 

$alpha = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcedfghijklmnopqrstuvwxyz1234567890";		
$rand = str_shuffle($alpha);		
$salt = substr($rand,0,40);		
$hashed_password = sha1($salt . $_POST['password']);

won't your $salt change each time it is called

 

Yes, it does. But that is why each salt value that is generated is being stored in the database table.

 

This results in a different salt string for each different member and it means that if someone does get a hold of the database table, they must try to crack that member's password individually using the salt value that is specific to that member.

RalphLeMouf, you need to define what you are going to do before you write any code to do it. Which is really why this thread has not been solved yet. Someone pointed out above that your code is putting the hashed passwords for newly created accounts in a column named Password and the hashed passwords for pre-existing accounts in a column named encrypted_passwords. Until you put all the hashed passwords into the correct column and use that column in your code that is checking if the entered password matches what is stored in the table, your code won't work.

 

If ALL the hashed passwords, both for new members and the pre-existing members was in your encrypted_passwords column, then the previous single query I posted that would perform all your logic directly in the query would be -

 

$query = "SELECT id FROM cysticUsers WHERE Email = '$email' AND encrypted_passwords = SHA1(CONCAT(salt,'$password')) AND Status = 'active' LIMIT 1";

 

All you would need to do is check how many rows the query matched and retrieve the id column if the query did match one row.

 

Also, your originally posted code was using mysql_real_escape_string() on the $email and $password variables. I recommend that you put that code back in since you are putting the $email value from the form into the query and my suggested query is also putting $password into the query.

I failed to point out that I work in dev environment. I am not using my real mysql database to make this. So for testing purposes I have it going to the `Password` column when you sign up and to the `encrypted_password` column when it's updating because when I put this on my real site. I want to keep the clear text column for a while just to make sure everything goes smoothly. I feel like my latest stab at this is the closest and want to stick with it. However my trouble shooting has hit a wall and I don't know how to see what is going wrong right now.

 

I would interject my experience here.

 

PHP's sha1, and mysql SHA1 will sometimes return different results.  Running sha1() on a password in PHP, and checking it against SHA1() password in MySQL will often result in a failed query.  To combat this, do it all in either PHP, or in MySQL.  Do NOT mix the functions between the two.  This is for any hash function.

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.