Want the big picture, how does salt work?

[floridaflatlander]

I was wondering how most people use salt or what is the order of the steps to use salt?

 

Does the script take the new password then encrypt it then add salt and in encrypt it again, are they just added together and then encrypted or is it a combination of something like that?

 

And I guess the de-encrypting would be the reverse.

 

Not looking for code just the big picture.

 

Thanks

S

[fugix]

http://pbeblog.wordpress.com/2008/02/12/secure-hashes-in-php-using-salt/

[floridaflatlander]

Thanks: very good reading, the best I've seen, this is the first I came to that said you can do it like this or like that, it's up to you. The stuff I found in my searches said do it like this and I kept having a gut feeling that it was up to the person doing the coding how it was done, thanks.

[fugix]

Thanks: very good reading, the best I've seen, this is the first I came to that said you can do it like this or like that, it's up to you. The stuff I found in my searches said do it like this and I kept having a gut feeling that it was up to the person doing the coding how it was done, thanks.

no problem, glad it helped

[xyph]

It's not a bad reading.

 

I prefer using a random salt mixed in with the hash though. He uses a hash based on the initial password, which is VERY easy to reverse if the attacker has even one known pass->hash combination. Here's a rather complex approach I use. You can even vary how the salt is stored based on password length to add even more complexity without adding too much overhead.

 

Ideally, the point of password salt-hashing is in the event of a total database compromise, you can rest easy knowing the attackers will have an extremely hard time getting your users passwords in plain text.

 

<?php

// Unique key - I use this to add further entropy between sripts, or multiple
// implementations within a script. It will further be used in hash_hmac, which
// forces an attacker to use a custom rainbow table for your site EVEN IF they
// manage to extract the salts, and learn how the salt is mixed in pre-hash
$key = 'ANY RANDOM STUFF CAN GO HERE. CAN BE LONG, CAN BE SHORT. I LIKE AT LEAST 20 CHARS';
// I plan on splitting the salt in half, and storing it in variable spots within
// the hash. This will tell us where the second split happens
$split = 6;


$password = 'FOOBAR';

$hash = make_hash( $password, $key, $split );

// The cool thing here is EVERY time you refresh the page you'll end up with a VERY
// different hash. If two users enter the same password, the chances of the hash being
// the same is miniscule.
echo "The hash of $password is $hash<br />";

if ( compare_hash($password, $hash, $key, $split ) )
echo "Passwords match on comparison";
else
echo "Something went wrong!";


function make_hash( $pass, $key, $split ) {

$passLength = strlen( $pass ); // Get the length of the password
// If the password is really long, we dont want to push the salt
// to the far end of the hash.
while ( $passLength > 30 ) $passLength -= 30;
$salt = uuid();
$hash = hash_hmac( 'sha256', $salt.$pass, $key );
// Mix in the salt with the hash
return substr($hash,0,$passLength).substr($salt,0,$passLength).
		substr($hash,$passLength,$split).substr($salt,$passLength).
		substr($hash,$passLength+$split-1);
// Returns FirstPartHash.FirstPartSalt.SecondPartHash.LastPartSalt.LastPartHash
// The salt is mixed into the hash based on the password length, making it VERY
// hard to reverse.

}

function compare_hash( $pass, $compare, $key, $split ) {

$passLength = strlen( $pass );
while ( $passLength > 30 ) $passLength -= 30;
// Extract the salt from the $compare hash.
$salt = substr($compare,$passLength,$passLength).substr($compare,$passLength*2+$split,32-$passLength);
// Once we have the salt, build the hash and see if it compares.
$hash = hash_hmac( 'sha256', $salt.$pass, $key );
$hash = substr($hash,0,$passLength).substr($salt,0,$passLength).
		substr($hash,$passLength,$split).substr($salt,$passLength).
		substr($hash,$passLength+$split-1);
if( $hash === $compare )
	return TRUE;
else
	return FALSE;

}

// RF4122 UUID Generator v4 - I prefer this over uniqid() due to a constant 128bit
// output, and no use of the time function. It's pseudo-unique, but will work very
// well for our application.
function uuid( ) {
return sprintf( '%04x%04x%04x%04x%04x%04x%04x%04x',
        mt_rand( 0, 0xffff ), mt_rand( 0, 0xffff ), mt_rand( 0, 0xffff ),
        mt_rand( 0, 0x0fff ) | 0x4000,
        mt_rand( 0, 0x3fff ) | 0x8000,
        mt_rand( 0, 0xffff ), mt_rand( 0, 0xffff ), mt_rand( 0, 0xffff ) );
}

?>

 

If you'd like to know more about the script, let me know. I wouldn't suggest using it copy+paste (though it would work fine if you did), but it is a good learning tool.

[teynon]

Random hashes are going to be better than password based hashes. Just because your data is encrypted doesn't mean your database is safe if its compromised. In fact, even random hashes don't ensure anything. This is where longer hashes and longer password requirements come into play. The way to hack into a database and reveal all the information is by process of elimination. Therefore, if your hash is huge and your customers passwords are huge, chances are, they are going to have a much much harder time cracking it. It's a matter of how much computer power they have. I don't remember what specifically it's called, but I think its like "Rainbow Algorithms" or something like that. Given a lot of free time and a big enough profit, I could make a database hacking program pretty easily. (With time.)

[xyph]

Rainbow Tables are what you're thinking. Rainbow tables are pre-computed hash tables. It pretty much allows you to plug a hash into a database, and if the result has been pre-computed, you'll get the plain-text that was used to make it.

 

There are no known 'algorithms' that make cracking a real hash easier. A strong, cryptographically secure hashing algorithm (sha256+,haval256+) will be broken only by brute-force. Rainbow tables speed up the brute force. A salt added to your hash makes the brute force harder. Eventually, if an attacker manages to brute force a known passworded hash, your salt will be revealed.

 

A random salt makes the brute force impossible, unless the salt can be extracted. Once the salt is extracted, the same steps are required above to figure out how you've mixed in the salt with your password to get your hash. If you've mixed in your salt with your hash variably, the attacker then has to repeat the same process for other known accounts to figure out how your salts are mixed. Keep in mind, if both your file system and your database are compromised, they have all the information they need to start brute-forcing plain text passwords, regardless of the complexity. This is where using a slower, longer (256+) algorithm will come in handy, as it slows down the brute-force and won't let them do a quick lookup on a Rainbow Table.

 

Teynon - I'll take you up on that challenge. I'll modify my script a little, and you can give me 10 passwords. I will give you 11 hashes. I will tell you which 10 are yours, and which one you will try to extract the salt from. If you can manage to extract the salt, I'll make it worth your time. I've given you a lot - you know the basic method, you know its salted, you know the salt will be variably placed depending on the password entered, and you have 10 sock puppets to compare to. To be honest, it's not worth taking up the challenge, because without knowing exactly how it's being done, each step I add makes it exponentially harder for an attacker to narrow down my algorithm.

[teynon]

Xyph, as I said, with the right amount of time and payment. I'm saying this would be your day job is cracking this database, because the results you get from it are way more rewarding. But realistically, getting a database, they aren't after your passwords anyway. They are after email address and other information. They make more money off of selling your contact information than trying to steal your passwords.

[xyph]

And as I'm trying to say... Even if this is your day job, you probably aren't going to beat it. For one, it's using hash_hmac with a private key. You couldn't start brute forcing without it as far as I know :/

[floridaflatlander]

I prefer using a random salt mixed in with the hash though.

 

That's what I'm going to do.