Jump to content
Larry Ullman's Book Forums

Hash_Hmac() Problem Loggin In


Recommended Posts

I want to change from SHA1 to hash_hmac() as you suggest.

I am able to update the database but not retrieve that user, i.e., I can Register but not Login. The mysql type is varbinary(128)

 

Here's how I get the password.

$p = mysqli_real_escape_string ($dbc, hash_hmac('sha256', $pass, PKEY, true));

 

When I echo $p it looks correct--it has weird characters.

When I look at database the password is alphanumeric, without any weird characters. I think that's where my problem is but I don't know why.

 

Here's the select query:

$q = "SELECT id, purchased, username, email, first_name, last_name, agreed, sinedup, active, DATE_FORMAT(lastlogin, '%b. %e, %y') AS ll FROM $TheTable WHERE (username='$u') AND (pass='$p')";

Link to comment
Share on other sites

Should I not use the bound statement here?

When I use this type binary, the database is empty for password.

When I used type string, it was alphanumeric.

 

 

$q = "UPDATE $TheTable SET pass=? WHERE id=? LIMIT 1";

$stmt = mysqli_prepare($dbc, $q);

mysqli_stmt_bind_param($stmt, 'bi', $p, $uid);

Link to comment
Share on other sites

I'm not using SHA1() anymore.

 

I'm using the following:

$p = mysqli_real_escape_string ($dbc, hash_hmac('sha256', $pass, PKEY, true));

 

$q = "UPDATE $TheTable SET pass=? WHERE id=? LIMIT 1";

$stmt = mysqli_prepare($dbc, $q);

mysqli_stmt_bind_param($stmt, 'bi', $p, $uid);

 

and the database type is varbinary(128)

Link to comment
Share on other sites

I'm sorry. I was reading this backwards and assuming you were going TO SHA1(). What you have looks correct, although I will say that use of $TheTable is really problematic for me, but not technically problematic.

 

I would first try running the query without using parameters so that you can rule out or identify the bound parameters as a problem.

Link to comment
Share on other sites

That's ok. I noticed it seemed you read it wrong.

I will try the query without the bound parameters.

I really can't think of any other reason for the problem.

That very same query worked when I was using SHA1(), although I also had my database type varbinary when I should have used varchar.

Link to comment
Share on other sites

I have it working now because not using bound statements.

But when I echo it shows weird characters and when I look at database it is alphanum.

Does it matter how long the key for hash_hmac is?

 

Why is it so unsafe to use variables for tablenames?

Link to comment
Share on other sites

The length of the key impacts the security only.

 

I worry about the use of $TheTable for a couple of reasons. First, it means you're not using a consistent naming scheme for your variables (compare with $uid), which can lead to bugs. Second, unless it's a framework or a CMS, most sites run queries on a known table in advance, so it shouldn't be necessary. Third, it's not clear where this variable comes from. And, fourth, using the variable for the table name made open you up to SQL injection attacks again, even if you were using prepared statements.

Link to comment
Share on other sites

How long should me key be, for best security?

 

My tablenames are good.

The reason I do it this way is because I have separate tables for testing.

Like this:

if (LIVE == false) $TheTable = $tUsersTable; else $TheTable = $UsersTable;

Otherwise I have to test thoroughly, both the live and test code, because one typo makes the live code wrong even though test code is good.

 

But I really don't understand why the tablename variable is unsafe but the following $q variable is safe:

$q = "UPDATE Users SET salt='$salt', pass=CONCAT($salt,'$p') WHERE id='$uid' LIMIT 1";

$r = mysqli_query ($dbc, $q)

 

There is a secondary reason I use the tablename variable, although this I could change. Already I had to rename all my tablenames when I changed webhost. If this happens again, I just change my variables instead of editing throughout the code.

Link to comment
Share on other sites

There is no "best security", you have to match the security to the application. But go with 12 characters to start.

 

Your use of live/test tables is unconventional; I've not seen it before. Normally one would have test/live databases (with the table names the same). But I gather that's not an option for you. Also odd that you would have to change tablenames when changing hosts. It may be time to pony up a bit more money for a better host.

 

As for $TheTable vs. $q, knowing why one is safe and the other is not is important to understand SQL injection attacks. The $q variable is not being used in your query. It stores your query. $q never gets to the database. $TheTable is part of the query and does get to the database, which makes it more of a security concern.

Link to comment
Share on other sites

I don't understand why unsafe to use variable for tablename.

When I echo $q, php has already inserted the tablename so MySql sees the same query whether hardcoded or variable.

But if this really is unsafe then can I use a php Constant for the tablename?

Link to comment
Share on other sites

 Share

×
×
  • Create New...