Comments on: PHP Password Security

By: ed

ed — Fri, 16 Jul 2010 01:01:56 +0000

wouldnt it be better to do

return $salt . hash($algo, $pass . $salt . $pass)

instead of just $salt . hash($algo, $salt . $pass)?

that way the attacker won’t even figure out were the (2nd) salt is?

By: Php database password

Php database password — Sun, 13 Jun 2010 02:38:39 +0000

A question. I have seen lots of questions but no real answers to this one for php security.

I hate placing the connection information for the mysql database connection in any form of plain text, even in my code.

It seems like there “ought” to be a way to use hashing etc. to create a more secure method, perhaps pulling the connection info from a file with the file only storing the hashed key, etc. and pulling the salt from a completely separate locale…

Thoughts?

By: Anders Törnkvist

Anders Törnkvist — Tue, 01 Jun 2010 23:49:46 +0000

In addition, it is important to remember that every login request preferably should be over SSL or otherwise the password must not be transmitted in clear text (for example, instead of using SSL the password could be hashed with Javascript by the client using the salt stored in the DB on the server (the server supplies the salt on AJAX request) and then this hash should be hashed (using the same or another hash method, the salt should this time be randomized by the server for every login attempt) before transmitted to the server).

By: Peter

Peter — Tue, 18 May 2010 19:17:34 +0000

Ah thanks a lot, i did not see that the salt is added to the hash again. Excellent article!

By: Richard

Richard — Sun, 16 May 2010 18:13:45 +0000

Peter, you store the hash and the random string in the database, then use the same random string when comparing. I concatenate the random string with the hash when saving it, then split them apart again when comparing.

By: Peter

Peter — Sun, 16 May 2010 15:28:39 +0000

Sorry, i dont get it. You mix a random string with the password, hash them and when you try to compare the password again, you generate another random value and hash it with the password?

If your random strings are not equal (which should be the case in most of the times) how do you get the same hash value again?

By: max

max — Sun, 09 May 2010 16:05:23 +0000

I totally agree with you about functional speed. The problem is all these algorithms have been developed/designed for speed and there is always gonna be a faster computer coming out next year, not to discount the mainframes of today. Personally I like exponential algorithms which can really tick down CPU and also involving various types available which is problematic if you are depending on what only comes with the package. Ideally it means a separate executable which PHP calls on to hash and then having an event to signal authenticity not to mention the timeout. If the result is as randomized as possible, and the executable is safe from reverse engineering. That’s basically all you can do. It does mean though that, commercially it’s not viable to release without compromising it’s security to possible disassembly. Best developed in-house, kept in-house and hush, don’t tell anyone.

By: Richard

Richard — Tue, 20 Apr 2010 17:10:05 +0000

I only have to make one request to the database to check the user’s login. The salt is returned as part of that request, along with the salted & hashed password.

I’m not clear of the value of your convoluted algorithm over simply using a good, robust hash algorithm.

By: Ariel

Ariel — Sun, 11 Apr 2010 06:37:34 +0000

The great thing is in your code is to create a second variable to hinder decryption.

If I understand your code, you will need to make one request to the database to get the Salt before comparing the password.

On my system I use the following idea.
1 – make only a single request to the database
2 – use two variables – (password and user)
3 – treat the password with different hash to minimize the collisions
5 – encourage the use of non-alphanumeric characters.
4 – Create a final string much larger than the hash to became the original data impossible to find.

some thing like this:


function goodLuckToFoundThePass($user, $password){

    $sha = md5($user).sha1('%&some^&name$/here'.$password, 'a').md5(strrev($user));

	$half = round(strlen($sha)/2);

	$sha1 = substr($sha, 0,$half);

	$sha2 = substr($sha, $half);

	$sha3 = $sha1 . 'the best way to create a secure password is making final string much larger than the hash to became the original data IMPOSSIBLE to find' . $sha2;

	$NewPassword = md5($sha3.$sha1, 1).md5($sha3.$sha2, 1);

	return $NewPassword;

}

Collisions? Maybe. 1 for pow(2,512);
but the ideia here is protect your users.

Ps: Sorry my English.

By: richard

richard — Sat, 01 Dec 2007 10:58:34 +0000

Nyna

Yes, due to potential collisions, a dictionary attack via the web interface is very slightly less secure than otherwise. But such attacks should prevented by other means. If you don’t protect against dictionary attacks then your site is vulnerable whether you use a hash or not, and if you do then it’s secure whether you use a hash or not.

The purpose of the hash is to protect against other types of attack that involve direct theft of your data.

You misunderstand the salt. Unlike a blowfish encryption key, the salt does not need to be secret for the hash to be secure. It only matters that the salt is used and is different for each password. The salt doesn’t protect against decryption (the nature of the hash algorithm does this), it protects against a rainbow table attack (a variant on a dictionary attack for hashed values).

Most companies who have lost their databases considered their security to be very good, yet the databases were still stolen. A similar level of security exists for your encryption key. If a criminal does access your server then they can access both your database and your encryption key.

And don’t assume hacking your production server is the only way in – Do you have backups or development servers that hold the code that contains the encryption key? How many employees know or have ready access to the encryption key? And do any other people have physical access to one of these systems?

With the hash algorithm above, criminals cannot find the passwords by hacking the server or stealing backups. Even I can’t find my users’ passwords.