hello all.. I have been getting this error and I don't understand why cause I have used the same code for another project and it works fine.
This is the error I get:
Fatal error: Call to undefined function: hash() in /home/content/u/n/e/uneedvac/html/admin/index.php on line 14
the code I used is this:
$userpass = hash('md5', $_POST['upass']) ;I was thinking maybe the server doesn't support it?
Anyways, please help 
Is it possible that you are using php5 on the server that works, and php4 on the server that it doesn't?
To that end... why use the [man]hash[/man] function when you can use [man]md5[/man], [man]sha1[/man] and any other [man]mhash[/man] algorithm you wish.....
bpat1434 wrote:Is it possible that you are using php5 on the server that works, and php4 on the server that it doesn't?
To that end... why use the [man]hash[/man] function when you can use [man]md5[/man], [man]sha1[/man] and any other [man]mhash[/man] algorithm you wish.....
Yes I just checked on one server php4 is installed and on the other it's php5.
So what would you suggest using in this case ? which is the safest algorithm?
Depends on what you're doing. What are you doing?
bpat1434 wrote:Depends on what you're doing. What are you doing?
I'm making a login system that checks with a username and pass from a mysql db.. it's only 1 user though
md5() should be fine. You can improve the security a bit by using a "salt" value.
$salt = 'mOleCuleZz';
$userpass = md5($salt . $_POST['upass']);
Of course, you need to use the same "salt" for all insert, update, or select queries of the hashed password.
(Enforcing the use of "strong" passwords is still important, though.)
However, md5 is not exactly "fine" since it is crackable now. You're better of using SHA1 or one of the mhash functions.
A good rule of thumb is to use the username as a salt. It's easy, it's unique (well should be) and it's constant (well, should be).
A better hash function is:
$user = $_POST['username'];
$pass = $_POST['password'];
$pass = sha1(md5(substr($user, 0, 6) . $pass));Now, that would require all your users to have an username of 6 characters or more. You could do one better and say that usernames are no shorter 8 characters in length and do something like:
$user = $_POST['username'];
$pass = $_POST['password'];
$pass = sha1( md5(substr($user, 0, 4)) . md5($pass) . md5(substr($user, 4, 4)) );You can be as creative as you want when doing the encryption. You could go character by character and entangle them together. For example, if you never have a password of over 36 characters + the length of the username:
$hashUser = $user = $_POST['username'];
$pass = $_POST['password'];
$alpha = 'aBcdEfghiJklmNopqRstuvWxyz0123456789'; // Will be used later...
$max = strlen($pass); // # of characters in password
while(strlen($hashUser) < $max)
{
$hashUser .= $alpha;
}
$plain = '';
for($i=0; $i<$max; $i++)
{
$plain .= $hashUser[$i] . $pass[$i];
if($i == $max-1)
$plain .= $hashUser[++$i];
}
$pass = sha1(md5($plain));You can become more secure using the mhash library from PHP, or you can stick with the basics. I would suggest sha1 over md5 just because md5 can be cracked if tried. Sha1 has the issue of collisions (as does md5) so it's your choice. You can also look into crc32 or sha256 with the mhash function to reduce collisions and improve security.
[EDIT]
I updated the lower code, now it actually works and works well 
To that end... why use the hash function when you can use md5, sha1 and any other mhash algorithm you wish.....
The PHP manual states that "the Hash extension requires no external libraries and is enabled by default as of PHP 5.1.2.". On the other hand mhash "has been moved to the PECL repository and is no longer bundled with PHP as of PHP 5.3.0." (which admittedly is not yet released).
However, md5 is not exactly "fine" since it is crackable now. You're better of using SHA1 or one of the mhash functions.
To be fair, MD5 is not broken for preimage attacks. Finding a password given only its hash is a preimage attack, not a collision attack. Still, I see no reason to use md5() when sha1() is available with or without the hash and mhash extensions and would slow down an attacker trying a brute force method.
You can be as creative as you want when doing the encryption. You could go character by character and entangle them together.
I do not see the point of that since it is unlikely to improve on what the hash function does. Hashing multiple times would at least slow down a brute force attack, but still may not make the resultant hash function stronger other than that.
As such, I would suggest sticking to something as simple as what NogDog suggested, perhaps swapping the hash algorithm with SHA-1 or a SHA-2 algorithm (like SHA-256) and possibly hashing twice (once on the original password, and then another time with the salt). If usernames cannot be changed, then using them as the salt would be fine. In the end this hashing just protects your users in the event that the database is compromised since users are known to reuse passwords.
To be fair, MD5 is not broken for preimage attacks.
Woops.... I guess I either read it wrong, or typed what I meant wrong....
I do not see the point of that since it is unlikely to improve on what the hash function does. Hashing multiple times would at least slow down a brute force attack, but still may not make the resultant hash function stronger other than that.
There was no point, just an illustration of creativity in password "obfuscation" for later, or just general knowledge.
laserlight wrote:I would suggest sticking to something as simple as what NogDog suggested, perhaps swapping the hash algorithm with SHA-1 or a SHA-2 algorithm (like SHA-256) and possibly hashing twice (once on the original password, and then another time with the salt).
I'm using php version 4.3.11 is it possible to use SHA-2 algorithm?
I tried the MHASH_SHA256 algorithm but that doesn't work. Gives error
Call to undefined function: mhash()Any other options for this?
Nope, not currently. mhash has to be enabled in your php installation in order for you to use it.
You could try using the [man]crypt[/man] function using other algorithms.
SHA-256 isn't completely endorsed by everyone yet, so the only way to get support for it in PHP (that I can tell) is with the mhash extension. SHA-1 is still perfectly valid and useful. The only reason people are moving to SHA-2 is because there is less of a chance of collisions in SHA-2.
I'm kept it simple and used SHA1.
I wanna thank you all for ur help I learned alot today... tnx again
I'd also like to point out that hashing of passwords is only an attempt to protect the password should your database become compromised. Now, should the database become compromised because someone has hacked your web host log on, such hashing will be useless since the hacker has access to your scripts' source code and therefor will be able to figure out exactly what hashing method (and any salts) you are using.
Such password hashing techniques are just one layer of the security onion, and are probably one of the less important ones. Much more important would be using SSL so that the client/server data interchange is encrypted (preventing a sniffer from capturing login info), implementing techniques to deal with repeated login failures on a given account and/or from a given IP address, and protecting all system passwords and making sure they are "strong" passwords, e.g.: host login, FTP login, database users/password, etc. (and site users should be forced to use "strong" passwords, too).
Now, should the database become compromised because someone has hacked your web host log on, such hashing will be useless since the hacker has access to your scripts' source code and therefor will be able to figure out exactly what hashing method (and any salts) you are using.
Not quite. Of course, it does depend on whether the users use good passwords in the first place, but with hashing at least the attacker is unlikely (or requires substantial effort) to be able to determine their original passwords. That the attacker knows what exactly is the hashing process does not matter since this is not security through obscurity.
If the attacker has the hashed passwords from the database and your source code, then he knows the hashing type used and any salts. Then all he has to do is run a dictionary of common passwords through the same hashing procedure, and look for matches in the DB. If none are found (because you enforced strong passwords on the users), then he may try a brute-force process until he finds a match. (Remember, if he's gotten all this info, he can set up the data on his own computer and run the hacking script for hours or days, if he is determined enough.) But, of course, that may all be academic, since if he got far enough into your system to get the data and the algorithm, he's likely far enough in to just set up his own account. I just wanted to point out that no hashing mechanism is uncrackable if the attacker has enough info, enough knowledge, and enough time; so do not depend on it as your only method of login protection.
Then all he has to do is run a dictionary of common passwords through the same hashing procedure, and look for matches in the DB. If none are found (because you enforced strong passwords on the users), then he may try a brute-force process until he finds a match. (Remember, if he's gotten all this info, he can set up the data on his own computer and run the hacking script for hours or days, if he is determined enough.)
Right, there is the question of whether the attacker is determined enough, and has enough time and computing power. Since salting is used, he can only work on one hashed password at a time. Then, he might end up with preimages different from the original passwords. For all that, he may not even be able to use the passwords found if the users whose passwords he found do not reuse their passwords, or if he is unable to determine other places where the users have reused the password found.
But, of course, that may all be academic, since if he got far enough into your system to get the data and the algorithm, he's likely far enough in to just set up his own account.
I agree.
so do not depend on it as your only method of login protection.
hmm... but it is not a method of login protection. It is a method of storage protection. It seems to me that there is no login protection at all from this since the original password would be sent in the clear unless something like SSL/TLS is used.