[SOLVED] hash() + mysql_real_escape_string() + MySQL query = blank field?

[etabetapi]

Hi, I've got a script that hashes user passwords, escapes them, and then stores them in a Mysql database. The issue is at home it works fine, but on my web host, the password field ends up blank. All other fields insert correctly (name, email, etc,) just the password field stays empty. No error message on insertion either.

 

My web host says its because we use two different versions of MySQL and the mysql_real_escape_string() function. They use MySQL 4.1.22, and I use MySQL 5.0.51a. The MySQL manual says that everything from MySQL 4.1.20 supports the function, so I think my web host is just giving me the run around.

 

I'm tired of dealing with them and getting these sort of ridiculous half-answers so I was hoping someone here might be able to help me out. I have included the code that I use just to cover all bases. Please let me know.

 

 

$userPass = "test1234";
$encryptPass = hash('sha256', $userPass, true);
$encryptPass = @mysql_real_escape_string($encryptPass);

require_once('connect_db_sths.php');

$query = "INSERT INTO members (`username` , `age`, `address`, `state`, `country`, `email`, `password`) VALUES ('$userName', '$age', '$address', '$state', '$country', '$email', '$encryptPass')";

mysql_query($query) or die("Unable to insert the record: " .mysql_error());
mysql_close();

[discomatt]

Try echo'ing the string after you run mysql_real_escape_string on it. Is it empty?

 

And, just for the record, you shouldn't have to escape hashed data. It is actually recommended not to

[PFMaBiSmAd]

If you read the php manual for the mysql_real_escape_string() function you will learn that it requires a connection to the database server or it will generate an error, which I am guessing is why you have the @ in the code to suppress the resulting error message.

[discomatt]

I really should start looking at code first

 

The error suppression keyword should only be used AFTER you know the script is working

[PFMaBiSmAd]

The @ never should be used. A live server should have display_errors set to OFF to prevent the display of errors but all errors should be logged so that you have a record of when and what is happening that is unexpected (such as when a hacker feeds invalid data to your script in an attempt to break in or to shut down your site by deliberately triggering errors...)

[etabetapi]

Try echo'ing the string after you run mysql_real_escape_string on it. Is it empty?

 

And, just for the record, you shouldn't have to escape hashed data. It is actually recommended not to

 

Try echo'ing the string after you run mysql_real_escape_string on it. Is it empty?

 

And, just for the record, you shouldn't have to escape hashed data. It is actually recommended not to

 

This is the result when echo'd, so the string is not empty.

 

“~_»H½IISlÖ[5Ä&¸ /ƒ\0Ž,ÞÄ"®"D

 

As for not having to escape hashed data? I was having problems before escaping the data where about 1/3 of the time I was not able to authenticate users, even if their password was correct. I guessed it was because of single quotations in the hashed string that were causing incomplete insertions, e.g.

 

"INSERT INTO members (`password`) VALUES ('12'3')"

 

Means I'd only be inserting 12 and not 12'3 as entered, correct?

 

Here's what the PHP manual has to say about mysql_real_escape_string and binary data:

 

If binary data is to be inserted, this function must be used.

http://au.php.net/mysql_real_escape_string

 

So now I'm confused. The hash returns binary data (thats what the true argument specifies, for whoever is too lazy to look it up) and I'm not supposed to escape hashes, but _am_ supposed to escape binary?

 

???

[etabetapi]

The @ never should be used. A live server should have display_errors set to OFF to prevent the display of errors but all errors should be logged so that you have a record of when and what is happening that is unexpected (such as when a hacker feeds invalid data to your script in an attempt to break in or to shut down your site by deliberately triggering errors...)

 

 

Ah ok, that makes sense. I didn't know live servers would set display_errors to OFF, and I didn't want the user bombarded with warnings. I did use the error suppression on my machine after I got everything working correctly and forgot about it once I uploaded it to my web host.

 

If I want to see the logs on my web host, how would I do that? Do I need to contact technical support?

[etabetapi]

I figured out the error. I'll just copy and paste what I sent to my web host regarding the problem:

 

Okay, I have figured out and fixed the issue by installing your server version on my machine. It was a security issue. My Wamp installation defaults MySQL to allow anonymous logins, while yours obviously doesn't.

 

When the function mysql_real_escape_string is called it tries to make a connection to a database to detect the character set used so it can make the appropriate modifications to the string. If no database link is specified, it simply tries to use the link from the last connection made.

 

In my code I was calling mysql_real_escape_string before I made a connection to the database, so the function defaulted to trying to connect using the login details OCDB@localhost with no password. When it could not connect, it tried anonymously. It was able to do this with my installation but not with yours. That is why the data would mysteriously disappear in transit, it was just dumped if no connection could be made.

 

So there you go. The database connection has to be made before calling mysql_real_escape_string if you want to ensure your data actually gets there on a more secure setup.