unexpected T_VARIABLE

kreali

I have been going through this code and can't find why I keep getting this error:
Parse error: syntax error, unexpected T_VARIABLE in /var/www/tools/calibre/admin/setupproc.php on line 82

Here is the code for lines 80 - 84, can anyone see what I can't? I'm sure it has to do with last part of the query, but just don't see it....

// store it in the database

$query = 'INSERT INTO user (name, username, pass, salt)VALUES('$_POST[name]', . dbSafe( $userName ) . ', ' .
dbSafe( $hashedPassword ) . ', ' . dbSafe( $salt ) . ')';
if ( !mysql_query( $query ) ) exit( "couldn't add new record to database because:" . mysql_error());

NogDog

It's an issue with the quoting. You might find it easier to do something like this (I'm assuming your dbsafe() function adds quotes around non-numeric values?):

$query = sprintf(
	'INSERT INTO user (name, username, pass, salt) VALUES(%s, %s, %s, %s)',
	dbsafe($_POST[name]),
	dbSafe( $userName ),
	dbSafe( $hashedPassword ),
	dbSafe( $salt )
);

kreali

Thanks alot. That worked like a charm. Now I just need to unhash it for the login. This won't change how that works will it?

bradgrafelman

kreali;10993911 wrote:
Now I just need to unhash it for the login.

What do you mean? In cryptography, a "hash function" is a one-way encryption scheme (often producing a fixed-length output). In other words, assuming you're using a good (or "resistant to a first-preimage attack") hash function, there is no way to retrieve the original data if given the hash value.

Weedpacket

You'd hash the supplied password (with the salt) and compare the result to the hash that's in the database.

kreali

I'm trying to crack it, I am securing passwords for a database by encrypting them with hash and salt and still want the user to be able to login with their combination. Are you saying that I am using the wrong method to do this?

kreali

I mean, I'm NOT trying to crack it..... sorry of the typo.

bradgrafelman

kreali;10993931 wrote:
Are you saying that I am using the wrong method to do this?

Are you doing what Weedpacket suggested above? If so, no. If not, then most likely yes.

kreali

No, I didn't do that. Back to the drawing board for abit..... Thanks.

bradgrafelman

Did you at least understand the approach he suggested? You don't need to know what the original password was that resulted in the hash stored in your DB; instead, you simply need to take the password you were given from the login form, combine it with the same salt used before, and see if the hash of that combination matches the hash you previously stored in the DB.

In other words, rather than working backward from a known good hash, you're simply working forward with a possibly good password and checking to see if you end up at the same place.

kreali

Somewhat. I am new to PHP so what I did was added the salt as a 9 digit random number to the password and created a hashed/salted password variable and stored this in the database. I would rather use SHA256, but couldn't get it to work. But, this seemed to work for now.

$salt = rand();
$hashedPassword = SHA1( $userPassword . $salt );
// store it in the database
$query = sprintf(
'INSERT INTO user (name, username, pass) VALUES(%s, %s, %s)',
dbsafe($_POST[name]),
dbSafe( $userName ),
dbSafe( $hashedPassword )
);
Now I have a login page and need to rehash the password and match it with what is stored in the database correct? It's the PHP code that I need to work out for the login page now....

kreali

I don't think using a "random number" is going to work because I can't combine it with the same salt... I didn't store the salt in the database because wouldn't that make it easier for someone to use the salt to ultimately come up with the hashed password?

Derokorian

Using a randomized salt means you won't be able to recreate that salt to compared hash values. This means that unless the rand comes out to the same number, you won't be able to create that hash again, so it won't be varifyable. This is my encrypt function, hope it helps:

function saltedHash($pass,$user) {
   $r = '1@3$5'.$user.$pass.'^7*9)';
   for( $i = 0; $i < 5; $i++ ) {
      $r = sha1( md5( $r ) );
   }
   return $r;
}

What this does is allow me to recreate the encrypted string if the password and username fed to the function are the same. IE:
saltedHash('pass','user'); will ALWAYS return the same string, where as you are basically changing user to a random number that's always randomly generated - how on earth could you recreate the string you hash if everytime the script runs a new number is going to be concantenated to the password?

bradgrafelman

kreali;10993944 wrote:
I didn't store the salt in the database because wouldn't that make it easier for someone to use the salt to ultimately come up with the hashed password?

If they compromised the entire database, then yes. But that's nowhere near the level of security threat that would be present if hash values could simply be reversed to reveal the original password, don't you think? 😉

Weedpacket

bradgrafelman wrote:
If they compromised the entire database, then yes.

Although not as much as kreali might be thinking....

If the password alone is hashed (without any salting) then existing dictionary attacks can be used to discover all of the commonly-used passwords (and a lot of them are commonly used) so that, for example, reversing the SHA-1 hash "f3bbbd66a63d4bf1747940578ec3d0103530e21d" is little more than a Google search away.

Salting blocks this. Even if the salt is known to be "23923" it doesn't help the dictionary attacker, because "common-password23923" is much less likely to be in the dictionary in the first place. The attacker would need a new dictionary - one in which every "common password" has "23923" appended. And with the salt varying from user to user....

While knowing part of the salted password might theoretically give a handle on cracking the rest, modern hash algorithms are designed with the aim of making the task at least as difficult as brute-forcing is tedious.

With the ever-increasing availability of computing power, of course, more elaborate attacks combining brute-force with analysis become more feasible. SHA-1 has already been deprecated in favour of the SHA-2 family (SHA224, SHA256, SHA384, SHA512; see [man]hash[/man]) and NIST expects to pick SHA-3 from among the remaining five contenders later this year.

kreali

This was all a huge help. Thanks for all the input, made a few tweaks and it's working nicely...
I may be back for more advise....great forum!! :-)