Jump to content

username and password not "seen" in MySQL table?


andybriggs
Go to solution Solved by andybriggs,

Recommended Posts

Hi Guys, 

 

I have a very simple table called: registered_users

 

there is only 4 columns 

 

column 1 = id

column 2 = username

column 3 = password

column 4 = salt 

 

the password is hashed and salted when it's added to the table. 

 

The problem is, that my username and password isn't being "seen" by the code so it's not sending me to the next page, it is only sending me back to the login page - not validated. 

 

Please could you help me understand what i may be doing wrong here, it all looks okay to me but that's not obviously the case? 

 

Here is the validation for username and password to login: 

/* validate the username and the password */
if((!isset($_POST['username'])) || (strlen(trim($_POST['username'])) <5) || (trim($_POST['username']) != preg_replace("/[^a-zA-Z0-9\_]/", "", trim($_POST['username'])))) {	
	/* if  is bad */
	$my_error = 1;
}else{
	$username = mysql_real_escape_string(trim($_POST['username']));
}
/* END validating username */

/* validate the password */
if((!isset($_POST['password'])) || (strlen(trim($_POST['password'])) <5) || (trim($_POST['password']) != preg_replace("/[^a-zA-Z0-9\_]/", "", trim($_POST['password'])))){
	/* if  is bad */
	$my_error = 1;
}else{
	$password = trim($_POST['password']);
}
/* END validating password */

/* if any of the post variables are invalid send back to the form page */
if($my_error != 0) {	
	$_SESSION['error_message'] =$error_message;	
	header("Location: index.php");
	exit();
}


/* FUNCTION TO CREATE SALT */
function createSalt(){
	$string = md5(uniqid(rand(), true));
	return substr($string, 0, 3);
}

/* check to see if username is in the table if not send back to login */
$query01 = "SELECT * FROM registered_users WHERE username = '$username'";
$result01 = mysql_query($query01)  or die(mysql_error());

if(mysql_num_rows($result01) != 1) {	
	header("Location: index.php");	
	exit();
 }


$row = mysql_fetch_array($result01);
$salt = $row['salt'];
$hash = hash('sha256', $salt, $password);
$query02 = "SELECT id FROM registered_users WHERE username = '$username' AND password = '$hash'";
$result02 = mysql_query($query02)  or die(mysql_error());
if(mysql_num_rows($result02) !=1){ 
	header("Location: index.php");	
	exit();
}
$_SESSION['id'] = $row['id'];
$_SESSION['valid_user'] = "yes";
header("Location: admin02.php");	
exit();
?>

Thanks

Andy

Edited by Ch0cu3r
Link to comment
Share on other sites

<?PHP
$username = "username"; /* this is going to be whatever you want as your admin username */
$password = "password"; /* this is going to be whatever you want as your admin password */
include ('db_conn.php');
function createSalt() {
	$string = md5(uniqid(rand(), true));
	return substr($string, 0, 3);
}
$salt = createSalt();
$password = trim($_POST['password']);
$hash = hash('sha256', $salt, $password);
$username = mysql_real_escape_string(trim($username));
$query = "INSERT INTO registered_users (username, password, salt) VALUES('$username', '$hash', '$salt')";
$result = mysql_query($query)  or die(mysql_error());
?>

Above is my code to add an administrator username and password. 

 

What's happening is if i enter the username and password it doesn't let me in. 

 

I have checked and the Admin username and password are successfully posting to the db table just not being read 

Link to comment
Share on other sites

Possibly a dumb question, but what's your mySQL column settings for both salt and password? Make sure they're able to hold the complete strings of both values and aren't truncating upon insert. The code looks fine to me (admittedly, I haven't had my second cup of coffee yet), so I'd start there.

Link to comment
Share on other sites

Hey maxxd, 

 

my settings for password are: 

 

name = password 

type = varchar 

length = 64 

not null 

 

my settings for salt are: 

 

name = password 

type = varchar 

length = 32 

not null 

 

 

Thanks for replying, i'm not a super whiz on the table settings for password and salt, should i be using different settings? 

Link to comment
Share on other sites

Sorry to keep updating my own post, but i'm now thinking it might be the session at the start, as what i'm seeing when logging in is the page going to index.php

<?PHP
session_start();

/* if it was not arrived here via the admin login form then destroy the session and send to index page */

if(!isset($_SESSION['what_page']) || $_SESSION['what_page'] != "admin00") {
	$_SESSION = array();
	session_destroy();
	header("Location: index.php");	
	exit();
}

This is the session created on the index.php page: 

<?php
session_start();

/* clear all session variable */
$_SESSION = array();

/* set a session variable for later use */
$_SESSION['what_page'] = "admin00";
?>

please could i have this checked over real quick

Link to comment
Share on other sites

your use of the hash() function is incorrect. the first parameter is the algorithm to use. the second parameter is the data. the third parameter is a flag that determines if raw binary data is returned or a hexadecimal value. by supplying a third parameter, you are getting back a binary value.

 

so, start over with your registration logic, then you login logic, and make sure the values you are generating and storing in your database table are what you intend. i recommend that you use the hexadecimal value (which is 64 characters for sha256) so that there are no possible conversion problems storing/retrieving the data (or change the column type to BLOB.)

Link to comment
Share on other sites

Yeah, 32 characters for the hashed password value is not enough. I'd up that to 64 or 128, then - as mac_guyver suggests - go back to the beginning and revisit your logic. Also, make sure you've got error reporting enabled.

Link to comment
Share on other sites

Thank you mac_gyver,

 

i have decided out the 2 options to change to BLOB. 

 

as for the incorrect usage of hash() function.

 

I thought it goes: 

 

1, use the SHA256 algo 

2. hash the salt (previously created) 

 

should i be adding raw output = FALSE to output hexis somewhere? 

 

 

I just tried with the now-changed BLOB type but i'm still being sent to index.php, what i'm struggling to understand is that this code previously worked in another database, and those databases have been destroyed so i'm trying to reverse engineer a mysql table via this code.  

Edited by andybriggs
Link to comment
Share on other sites

the code as posted, was only hashing the salt value. it is not hashing the salt and password, so any password would have matched.

 

for the hash() function, you need to read the php.net documentation.

 

as to why your code isn't validating the username/password, you need to find out exactly what your code IS doing so that you can find the problem. you have several points where the code redirects back to your index.php, and at least in the posted code, there's no values being used that uniquely indicates why.

Link to comment
Share on other sites

 

i have decided out the 2 options to change to BLOB. 

No, sha256  returns a hash that is 64 character string. All you needed to do was increase the character limit of your password field to 64 characters

 

 

 

as for the incorrect usage of hash() function.

You need to be concatenating $salt and $password together (a  period  between the two variables not a  comma) when you pass them to the hash function.

$hash = hash('sha256', $salt.$password);
Edited by Ch0cu3r
Link to comment
Share on other sites

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.