PHP 'nonce' advice

[shoebox]

Hi,

 

I'm new to the forum so I hope I'm in the right place.

I'm trying to develop a secure login & member system for a club website but am having difficulty in getting my head around salts and nonces for my registration & logon.

 

Here's what I do to reg:

$salt = "aB1cD2eF3G";
$salt .= $login;
$password = $_POST['password'];
$pass = md5($salt.$password);
//Create INSERT query
$qry = "INSERT INTO members(firstname, lastname, login, passwd) VALUES('$fname','$lname','$login','$pass')";

 

I know the salt is static & want to have it random; I think that's the idea of a nonce - but would I have to create a separate table for these nonces?

 

anyway; on my logon page I have this

 

$salt = "aB1cD2eF3G";
$salt .= $login;
$pass = md5 ( $salt . $password );
//Create query
$qry = "SELECT * FROM members WHERE login='$login' AND passwd='$pass'";
$result = mysql_query ( $qry );

//Check whether the query was successful or not
if ($result) {
if (mysql_num_rows ( $result ) == 1) {
	if (condition) {

	}
	//Login Successful
	session_regenerate_id ();

 

which works but i'm concerned with the problem above.

 

Finally, I just ahve this bit for nonce & timestamp:

// Security Checks
if (($timeStamp != $_SESSION ['TIME'])) {
$errmsg_arr [] = 'timeStamp amended: Security Hijack';
$errflag = true;
}

if (($nonce != $_SESSION ['RAND'])) {
$errmsg_arr [] = 'nonce missing: Security Hijack';
$errflag = true;
}

 

 

I get the RAND & TIME from hidden field.

 

I guess I'm just looking for advice.

 

Thanks,

 

SB

[JAY6390]

Random salts are pointless, since if your security is breached to the point where your passwords are accessible then so will the salts table/field which just makes it redundant. Stick with the single salt

[shoebox]

so I guess I stick with the salt I have then? from what you said that makes sense.

 

as for the nonce; if this is random and appended to the password when it is submitted - how do I match that with what is in the DB?

 

thanks,

 

SB

[MadTechie]

Random salts are pointless, since if your security is breached to the point where your passwords are accessible then so will the salts table/field which just makes it redundant. Stick with the single salt

 

Really.. you could use the same logic for storing as plain text passwords!

So when your website exposes all the passwords on a single sweep mine will require a lot more effort, I wonder who's users will feel more secure ?

 

Don't get me me wrong I do get your logic but I disagree that its pointless...

[JAY6390]

I'm not sure if you understand what it is I was saying. I agree that having a salt is a good idea, but a random salt is just as much use as a static one if you're storing them together. If you're going to brute them you have the salt and the hash, so it's just as breakable

[mattal999]

I'm not sure if you understand what it is I was saying. I agree that having a salt is a good idea, but a random salt is just as much use as a static one if you're storing them together. If you're going to brute them you have the salt and the hash, so it's just as breakable

In which case, isn't it better to have one static salt defined as a variable in a script, along with a randomly generated salt in the database? If you do this, then if a hacker gets into the database he cannot decrypt the password and if he gets into the files then he cannot decrypt it as he is missing one salt in each case?

 

Just a thought though, never actually tried it.

[JAY6390]

The first is correct yes, but if you have access to the files, you can get the database connection information and then get the salts for that (or even just use the sites built in functions to run the hack). This makes the database salt redundant again

[mattal999]

The first is correct yes, but if you have access to the files, you can get the database connection information and then get the salts for that (or even just use the sites built in functions to run the hack). This makes the database salt redundant again

True. I guess a static salt is more suitable then.

[JAY6390]

The only way to make it more secure with random salts is to have one salt server and one web server, whereby the salt and web server would need to be compromised in order to get password

[MadTechie]

I'm not sure if you understand what it is I was saying. I agree that having a salt is a good idea, but a random salt is just as much use as a static one if you're storing them together. If you're going to brute them you have the salt and the hash, so it's just as breakable

 

In part your right but overall you are wrong,

When it comes to brute force if the cracker has all parts to rebuilt the password then having random salts won't help (too much) however, brute force is the longest attack method, rainbow attacks are quicker as they are pre-calculated hashes,

so if you don't have a different salt for each user then a rainbow table can be built using the static salt and then that could be used on ALL users passwords.. but having a random salt it renders rainbow tables ineffective, as your need to create a new rainbow table for each user this proves ineffective thus your only real option is to use a brute force which is slower!

 

So to sum up

Clear text = 0 crack time

MD5 (no salt) =  rainbow table attack

MD5 (with static salt) =  Build custom rainbow table using static salt + rainbow table attack

MD5 (with dynamic salt) =  Brute force

 

and considering brute force takes the longest of all of them it would suggest that

[shoebox]

okay then; I understand then it's a hashed password with a dynamic salt.

So from my code above what's th best way to implement this?

 

So far I think I should....

when a user tries to log on the values submitted are username, password & nonce.

I cocatenate the nonce to the password & hash this value & post these values.

When checking if the passwords match server-side do I just get the password from the db via the select & appended & hash it to the nonce that was passed as hidden???

 

Thanks,

 

SB

[MadTechie]

I would have a static salt for the site (stored in a PHP file) and in the database have a random salt,  as mattal999 said

 

In which case, isn't it better to have one static salt defined as a variable in a script, along with a randomly generated salt in the database? If you do this, then if a hacker gets into the database he cannot decrypt the password and if he gets into the files then he cannot decrypt it as he is missing one salt in each case?

 

This make the cracking harder as they need to get both salts and the hash, (so they will need more than just DB access)

how you concatenate them is up to you,

 

you could

prefix the site salt and append the users salt,

you could

append or prefix them both,

you could

prefix the first half of both of them and append the second half of both of them..

you could

MD5 the one of both of the salts and append/prefix it

list goes on!

 

of course whatever method used need to be repeated to match the hash,

 

So you could do all this in SQL ie[untested]

$password = mysql_real_escape_string($_POST['pass']);
mysql_quey("SELECT UserID FROM Users where MD5(CONCAT(`dbSalt`,'$password', '$siteSalt')) = `dbPassword`");