BetterPHP

This function will salt a password and stretch it by 5120 rounds of encryption

<?php function passcrypt($username, $password)
{
	$coresalt = "XtyuNfG8AaX7CrerGaAaeEacCmQkRygdFvPu34"; /* or whatever random string you like to form the basis of the salt*/
	$usersalt = md5($username);											/* hashes the supplied username */
	$passlen = 6*strlen($password);										/* works out the length of the password and mutiplies it by three */
	$num1 = substr($passlen, 0, 1);										/* selects the first number of the length */
	$num2 = substr($passlen, 1, 2);										/* selects the second number of the length */
	$num3 = $num1 * $num2;													/* Multiplies both numbers */
	$truesalt = sha1($num3. $usersalt. $coresalt);				/* Conbines all variables and hashes the resulting string */
	$endresult = $truesalt. ":". $password;								/* Conbines $truesalt and $password */
	for ($i=1; $i < 5120; $i++)												/* Starts for loop and makes 5120 rounds */
	{
		$endresult = hash("sha256", $endresult);					/* Overwrites the variable */
	}
	return $endresult;																/* Returns the variable */

This is a similar, yet modified, version of the function used on my site

Seems good, but I'd rather make dynamic salts and store those salts in a MySQL DB not related to where the password is stored.

If somebody was able to obtain the hashed password, then they'd be able to obtain the salt as well then. Regardless of whether it is in the same table as it or not.

Most likely, the safest way to do salts is to store the salt in a file which is outside of root. That way, the file isn't readable by anybody unless they have direct server access. Also, within a file, you can have a salt of infinite length (I currently use a 2048 bit long string of binary digits)

Would there be any noticeable difference in security if you would go farther than 2048, or incorporate letters as well?
I'm thinking that 2048 bits is difficult enough to crack, so going bigger wouldn't necessarily mean being safer. Am I wrong here?

Temor wrote:Would there be any noticeable difference in security if you would go farther than 2048, or incorporate letters as well?
I'm thinking that 2048 bits is difficult enough to crack, so going bigger wouldn't necessarily mean being safer. Am I wrong here?

Bigger will always work better; however. It doesn't matter too much.

To be honest, 2048 is probably overkill anyway.

The issue surrounding the SQL table being dumped is virtually non-existent because although the bad guys have the user portion of the salt, they do not have the static key or a knowledge of how many times your password was hashed. They would only be able to retrieve the static part of your salt, as well as the number of rounds you use, if they grab the function code in which case you're really screwed.

wrichards8 wrote:The issue surrounding the SQL table being dumped is virtually non-existent because although the bad guys have the user portion of the salt, they do not have the static key or a knowledge of how many times your password was hashed. They would only be able to retrieve the static part of your salt, as well as the number of rounds you use, if they grab the function code in which case you're really screwed.

Okay so an MD5 hash itself takes ~80 CPU hours to crack from nothing, and 320+ for SHA256. Most bad people wouldn't want to wait that long to gain access for an account. So there are sites that use dictionaries found around the web to generate hashes, then store them in a system so that anybody can search the hashed string and get the actual password.

Hashes are stored in a way that makes them have one end string for each input string. For example; 'llama' will always be 'cb16cefd41d8c728b35361f776711ead' in MD5 format. So if a salt was 'XtyuNfG8AaX7CrerGaAaeEacCmQkRygdFvPu34' and was inserted at the front of the input string, the hash would look like: '4a4fd09e0d684984ad7a719b0358ff90'.

As far as I know, you can't crack part or some of an encryption (maybe base64 but that's easy enough to decrypt, if you could call it an encryption). Its either going to be 'XtyuNfG8AaX7CrerGaAaeEacCmQkRygdFvPu34llama' or nothing.

Just by looking at that, you can clearly tell what the password and the salt are, give or take the 34. If you wanted a secure salt, it would have to fit the pattern of the password. Like 'llamathenllama' would fit in to the password quite nicely, or have multiple salts. You may even be able to use random positions of salts.

MD5 and sha1/256 are quite lengthy hashes, but as far as computer technology goes these days, its simple enough to get the end input. My suggestion would be to use an odd hashing algorithm, like whirlpool or all the havals, and maybe even tiger. And if your PHP version is old enough you could use salsa

And yes there may be a very nice piece of code here, but because its here it can be Google'd. Yes I know there are many different secure password classes on the web, but with a very specific search query, anything can be found.

And without any login attempt limiter, this code could be obsolete. Sadly, brute-force is still around.

What I'm trying to say is, your system security is only as good as your password.