Wrote up a quick program to make a list of random salts for me and... no go

[133794m3r]

Ok i wrote up this program to help me make ~120 random salts for the login script to choose from. This is going to be of course appended on teh password and then hashed. I'm doing this of course to attempt to make it harder for someone who sees teh databases to find out people's passwords. currently teh bug is that the line breaks i attempted to add aren't working. I don't know why it just isn't working, and only showing the last one without any line breaks. And now onto the code.(also the text is just there for show really i was planning on taking it out and just forcing the thing to just auto-run in teh future but for now i thought it best to keep it in there for debugging purposes).

Code: [Select]

<?php
if ($_POST){
$chars = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890!@#$%^&*()_+=';
$value = 1;
// Generate a random character string
function rand_str($chars)
{
//sets the variables as global
global $string,$length,$chars;
//sets the length of the string as a random length
$length = mt_rand(20,60);
// Length of character list
    $chars_length = (strlen($chars) - 1);

    // Start our string
$string = $chars{mt_rand(0, $chars_length)};
   
    // Generate random string
    for ($i = 1; $i < $length; $i = strlen($string))
    {
        // Grab a random character from our list
        $r = $chars{mt_rand(0, $chars_length)};
       
        // Make sure the same two characters don't appear next to each other
        if ($r != $string{$i - 1}) $string .=  $r;
    }
   
    // Return the string
    return $string;
}
function w_str(){
//sets the variables as global
global $string,$chars;
// the for loop which'll generate 120 random salts
for ($value=1; $value <= 120; $value++){
//This calls forth our super function
rand_str($chars);
//this opens up the file to write to
global $value,$string,$chars;
$fp = fopen('data.txt', 'w');
//this writes teh data to teh file
fwrite($fp,$value.":".$string."\n");
fclose($fp);
}
}
w_str();
}
?>
<form method="post" action="hashmaker.php">
<input type="text" name="blah" />
<input type="submit" value="create salt"/>
</form>

[Nox]

global $string,$length,$chars; global $string,$chars; global $value,$string,$chars;....come on , no need, make them either parameters of the function or constants (those that won't change of course)
$length = mt_rand(20,60); ...the limit/range should be a parameter too

ad linebreakes....which OS? for Win try \r\n...not sure if it'll work, but that's the way it handles newlines

[JGadrow]

About the linebreaks... PHP includes a constant that will output the correct line ending convention for whatever system it is installed on:

Code: (php) [Select]

echo 'I\'m a sentence followed by a line break!' . PHP_EOL;

[133794m3r]

global $string,$length,$chars; global $string,$chars; global $value,$string,$chars;....come on , no need, make them either parameters of the function or constants (those that won't change of course)
$length = mt_rand(20,60); ...the limit/range should be a parameter too

ad linebreakes....which OS? for Win try \r\n...not sure if it'll work, but that's the way it handles newlines

O.o why should it be a parameter? It's meant to generate entirely random strings of text for me. And i never said the thing was perfect. I just was using it for my own purposes of generating a list of random salt to use.

Code: [Select]

fwrite($fp,$value.":".$string."\r\n"); doesn't work for some odd reason.. and neither does...

Code: [Select]

fwrite($fp,$value.":".$string.PHP_EOL);
am i missing something inside of the code here... is there some vast bit of information that i'm completely missing out?

[Nox]

Should you want to use it twice with different options, it would not be possible and it would make the function more universal,
using globals is in most cases bad habit and it's good to use function's parameters.... I know you didn't say it's perfect but neither you didn't forbid us from giving advice I surely didn't mean it in a bad way, sorry then

I missed the fact "only last line"...so the whole file contains only the last line?

Yea, now I see...you have the fopen, global, fclose all inside the loop... place it before/after it and it should...plus I'd rather make it one whole string and then use more comfortable function file_put_contents

[JGadrow]

As Nox stated, the reason you're only seeing the one line is that you're opening and closing the same file 120 times. Each time you're opening it you're specifying to open it in mode 'w' which tells it:

Open for writing only; place the file pointer at the beginning of the file and truncate the file to zero length. If the file does not exist, attempt to create it.

This tells PHP to erase the file and start from blank. Your code would work as written if you simply change the 'w' to 'a' as that appends the data to the current file. However, you'll be much better off if you open the file before the loop because there is a performance cost for accessing the file system. Your script will run faster and do what you expect it to.

Hope that helps.

[Harkins]

Why would you want a list of random salts? Why not just append the user's name to their password before hashing? Is there a purpose for salting besides defeating rainbow tables that I'm forgetting?

[JGadrow]

You are, indeed, correct. The only problem with making the salt the equivalent of the username or something else account-dependent is that it's easy to guess. Of course, you also need to store the salt somewhere unless you're using a static list of salts at specific intervals.

Using a file to store the available salts keeps the salt separate from the account information. If your account table is compromised, the attacker is likely to try hashing combinations of account information with their rainbow table to produce the desired hash. Assuming they're that dedicated to the pursuit.

However, if you have, say, 120 salts that you recycle based on a simple algorithm (uid % 120 = salt index) then you have a reliable means of determining the salt of a user account without a need to store it with the account information.

Now, you'd probably want to cache an object like this in your cache table (which still serves the purpose of keeping it separate from the account table) so that you don't need to constantly take the performance hit of reading the file contents. But, it just added an extra layer of security to the users passwords.

However, this scheme would still render the same hash if the users had the misfortune of choosing the same password and happened to be an increment of 120 accounts away because they'd be using the same salt. So, you should also count the account creation time + account name, or some other unique account feature to generate the salt. But, for greatest security, you should not have your salts based solely upon account information as that makes them easier to crack.

For greatest security, you should randomize your salts from time to time. You can do this by setting up a new set of salts. Then, you create an additional table specifying the user's current salt version. When the user attempts to authenticate, you pull their current salt object and test against that. If it's successful, you re-generate their password hash with your current salt object.

In this manner, you can shorten the attack window if your database is compromised. At least, for those accounts that are active.

[dsheroh]

Why would you want a list of random salts? Why not just append the user's name to their password before hashing? Is there a purpose for salting besides defeating rainbow tables that I'm forgetting?

No, there is not another purpose for salting, but using the username as the salt reduces the amount of entropy in the salt to a level which I consider unacceptable.  Not because the salt is guessable - conventional methods include the salt in the hashed password string anyhow, making it trivial to determine the salt without needing to guess it - but because of the clustering of salts that results.

With a random salt, an attacker wishing to use a rainbow table applicable to a range of targets needs to generate hashes corresponding to a substantial fraction of the potential number of salts.  Even a simple 4-character random alphanumeric salt gives a little under 15 million potential salt values.  If we're going after popular sites with an average of 10,000 users, then we'll need to cover about 1,500 salts in our rainbow table to be able to, on average, look up one valid password per system.

If the username is the salt, though, we only need three salts in our rainbow table - "root", "admin", and "administrator" - and we'll be able to look up a valid password on the vast majority of potential target systems, regardless of how many or how few users they have.  Not only that, but it will be a privileged account rather than a standard user account.

The benefit of salt in preventing rainbow table attacks is almost completely negated by using the username as your salt.

[133794m3r]

You are, indeed, correct. The only problem with making the salt the equivalent of the username or something else account-dependent is that it's easy to guess. Of course, you also need to store the salt somewhere unless you're using a static list of salts at specific intervals.

Using a file to store the available salts keeps the salt separate from the account information. If your account table is compromised, the attacker is likely to try hashing combinations of account information with their rainbow table to produce the desired hash. Assuming they're that dedicated to the pursuit.

However, if you have, say, 120 salts that you recycle based on a simple algorithm (uid % 120 = salt index) then you have a reliable means of determining the salt of a user account without a need to store it with the account information.

Now, you'd probably want to cache an object like this in your cache table (which still serves the purpose of keeping it separate from the account table) so that you don't need to constantly take the performance hit of reading the file contents. But, it just added an extra layer of security to the users passwords.

However, this scheme would still render the same hash if the users had the misfortune of choosing the same password and happened to be an increment of 120 accounts away because they'd be using the same salt. So, you should also count the account creation time + account name, or some other unique account feature to generate the salt. But, for greatest security, you should not have your salts based solely upon account information as that makes them easier to crack.

For greatest security, you should randomize your salts from time to time. You can do this by setting up a new set of salts. Then, you create an additional table specifying the user's current salt version. When the user attempts to authenticate, you pull their current salt object and test against that. If it's successful, you re-generate their password hash with your current salt object.

In this manner, you can shorten the attack window if your database is compromised. At least, for those accounts that are active.

I was going to do something similar to this with the random salts and switch them out every time i do maintenance putting in a new list of salts for the random generator to use. Also the idea of the static salt using the exact time that the user logged in or created the account sounds a bit odd to me atleast. For my static salt, i was going to generate one extra random salt and just use that as my static salt once again changing it out every maintenance. And now that i know exactly or well pretty close to exactly how to do the changing of the salts since i had a vague idea. I can now sit down and change that file and generate them and add them to my login script.

The other thing was/is going to be, the safest way to store said value for the salts is to just use the number corresponding to said random salt correct? I was going to put into the databases in the users table a column with the name of rs. And it's hold the value from 1-120(maybe more depends on how paranoid i feel). Then as you said, i'd add in another value simply stating if i need to update their hashed password after authenticating them. And then whenever they try to login, it pulls that value out, it goes and checks the function that holds all the salt values and then brings back the corresponding value that matches $rs=x. And that's added to the password for salting purposes.

The other thing was... does the salt placement increase securty in any way shape or form? I was currently thinking about setting it up as such.

$static_salt.$password.$random_salt and then hashing that. Is that any more secure or less secure than any other combination?

edit:And since it seems that php in and of itself is pretty fast with regards to radnomly generating this data(atleast on my home pc), about how many random salts should i use? Since i'm already using 3 digits, would 400 be out of the question? It apparently generates 401 in .243 seconds.

[Bryan]

Just being curious- are you using MD5 to encrypt and has anyone else heard that rainbow table attacks less effective against SHA encryption?  I keep seeing little blurbs on switching MD5 to SHA because of this, and really getting curious.  (I switched over to SHA because I figured at least it couldn't hurt, and use a little salt (typically a 32 char random string) changing/updating too, but not to the degree that you are talking)

[dsheroh]

Also the idea of the static salt using the exact time that the user logged in or created the account sounds a bit odd to me atleast.

Odd in what way?  That's actually the normal way to do it:  Generate a random salt when the account's password is set and store it with the password (usually as part of the hashed password string).

Your scheme with a list of pre-generated salts which are periodically rotated is what seems odd to me...  I've never heard of anyone doing that before and it's just going to add a lot of complexity for no substantial benefit.

For my static salt, i was going to generate one extra random salt and just use that as my static salt once again changing it out every maintenance.

Your "static salt" is more commonly called a "nonce".  Nonces are applied system-wide while hashing all passwords, while salt is only applied to a specific password.

Using both a nonce and salt is good practice, but, again, rotating nonces isn't going to buy you much aside from extra complexity.

The other thing was/is going to be, the safest way to store said value for the salts is to just use the number corresponding to said random salt correct?

It doesn't actually matter.  People who know a lot more about security than you or me are perfectly happy with prepending their salts to the password hashes with no external lookups at all.  If it's good enough for them, it's good enough for me.

So why doesn't it matter?

First, keep in mind that nonces and salt are completely irrelevant until and unless an attacker compromises your database and gets his hands on the account information table.  So long as your account data stays out of attackers' hands, you could just as well be storing your passwords in plaintext and it would still be secure.

Since we're worried about salt, then, we're assuming that an attacker has obtained our account data.  There are two sub-cases to consider:

1) The attacker has compromised only the database, giving him access to the data stored there, but nothing else.
2) The attacker has compromised the server overall, giving him access to your program's source code and supporting files in addition to the contents of your database.

In #1, the attacker does not have access to the static nonce which has been applied to all passwords.  Without guessing the nonce, he is incapable of correctly mapping a plaintext password to the corresponding hash as it would appear in your database, so any attempt to reverse-engineer passwords based on the data he has captured will fail.  This is completely independent of whether he knows each password's corresponding salt or not.

In #2, the attacker is able to obtain the nonce from your source code, allowing him to proceed with an attack.  It may appear that, in this case, storing your salts somewhere outside of your database would thwart him in this case, as he needs both nonce and salt to correctly hash an attempted password, but that's a flimsy protection when you consider that the source code will tell him exactly where to find your external list of salts and, if he has sufficient access to obtain the source code, then he will almost certainly also have sufficient access to obtain any external data used by the code when running.

The only time that storing salt externally will save you, then, is if an attacker obtains your source code along with your database and he fails to also copy your list of salts and you detect that your server has been compromised and you successfully re-secure the server to block his further access before he comes back to get the salt list.

Now consider how likely that scenario is.  Then consider the possibility that a convoluted scheme with rotating lists of external salts and constantly-changing nonces might end up containing subtle bugs that an attacker could exploit.  Weigh the two against each other and decide which is more likely.  I don't know about your code, but I consider the odds of mine containing bugs to be substantially higher than those of even the first step in that chain of events, so I keep it simple and just store my salts with the hashed passwords, the same as everyone else does.

$static_salt.$password.$random_salt and then hashing that. Is that any more secure or less secure than any other combination?

Provided you're using a good hashing algorithm, the order is completely irrelevant.  If you're using the traditional unix crypt() function, that would suck, but only because crypt() sucks - it ignores everything after the 8th character.  If you're using anything more recent, though - md5, shaN, bcrypt (use bcrypt if possible) - then every character will affect the resulting hash regardless of length, so the order doesn't matter.

edit:And since it seems that php in and of itself is pretty fast with regards to radnomly generating this data(atleast on my home pc), about how many random salts should i use? Since i'm already using 3 digits, would 400 be out of the question? It apparently generates 401 in .243 seconds.

Since it's so fast, use one unique salt for each password.  (But, then, I bet you already knew I was going to say that.)

[dsheroh]

Just being curious- are you using MD5 to encrypt and has anyone else heard that rainbow table attacks less effective against SHA encryption?  I keep seeing little blurbs on switching MD5 to SHA because of this, and really getting curious.  (I switched over to SHA because I figured at least it couldn't hurt, and use a little salt (typically a 32 char random string) changing/updating too, but not to the degree that you are talking)

MD5 has its problems and is widely considered to be "broken" for hashing stored passwords, but I haven't heard anything about it specifically being more vulnerable to rainbow table attacks, no.  The problems I've heard about are primarily related to either the existence of mathematical means to generate md5 hash collisions at will (although that's a bit of a red herring, as these techniques require you to know the source text that you want to collide with, so they're primarily applicable to the use of md5 as a signature) or that it's sufficiently parallelizable that you can buy FPGA cards that will process millions of md5 hashes per second (making rainbow tables obsolete because they can rip through a brute-force attack so fast).

SHA-N is a major improvement over md5, but bcrypt was specifically designed for password hashing (unlike md5/shaN which were designed for creating message digests) and I'm a big believer in bcrypt as The Right Way to do this.  I've already posted an explanation of its advantages on this forum at http://community.bbgamezone.net/index.php/topic,2667.msg18708.html#msg18708 so I'll point you over there instead of repeating myself here.

[133794m3r]

Hmm.... and well since honestly i've yet to see a bcrypt addon for apache/php i doubt i'll be able use that and i was using a sha256.

It just seemed odd to me to just store it inside of the database since the hacker if he gets ahold of only the databases(i'm of course going to try to do everything in my power to prevent them from doing so), they'd only have to guess the "nonce" as you call it. So to me it'd seem a bit less secure, but of course, if someone does get ahold of everything on the server then yes there'd be nothing to really stop tem as they'd have full access to it all.

Nvm i just noticed that blowfish is supported by php. Seems i'll try it out a bit. And start using it instead of sha256.

edit: But the problem i see is that they dont' let you specify how much of a delay you want to use... so i'm worried about that much.

[dsheroh]

It just seemed odd to me to just store it inside of the database since the hacker if he gets ahold of only the databases(i'm of course going to try to do everything in my power to prevent them from doing so), they'd only have to guess the "nonce" as you call it.

Keep in mind that my "nonce" is your "static salt", so that's a fairly big "only".  If you use, say, a 20-character random nonce, then that's going to be unguessable for all practical purposes.

Without your source code, the only way an attacker can determine whether a guess at the nonce is correct would be to make a known-plaintext attack by creating an account prior to stealing your database (so that they know at least one account's password) and then brute-forcing your nonce by trying different nonces and different ways of combining the password, salt, and (guessed) nonce to see whether their hash matches yours.  Even if they guess the right nonce, they won't get a match if they hash nonce-salt-password and you're doing nonce-password-salt.

Essentially, the nonce is a password which protects all of the other passwords.  Brute-forcing a 20-character password is not an easy task...

edit: But the problem i see is that they dont' let you specify how much of a delay you want to use... so i'm worried about that much.

Maybe take a look at http://www.openwall.com/phpass/ and some of the projects linked from there for examples of using it?  That is odd if you're not able to tune the cost, but I guess that could be either hardcoded into the PHP implementation based on the current tech at its release date or self-tuning based on the processor it's being run on.

Regardless, bcrypt will never be less secure than md5/sha, even if you can't slow it down further as technology advances.

BTW, thanks for all the security questions.  I'm an ex-sysadmin as well as a programmer, so I've known all this stuff for years, but it's good to be prodded into pulling it back to the fore and think the details over every now and then. 

[133794m3r]

np, i'm the type of person to ask questions alot b/c i generally want to know how things work and also most others here seems that there's people out there at least as paranoid as me. And if you stay around here, i'm sure you'll see alot more discussions such as this one.

[JGadrow]

dsher makes a lot of great points above. If a hacker ever gets system access to your server and has the ability to read your source code... then nothing has the ability to protect your users because they can download the database and they can download the source files. This eliminates any "attack window" help granted by re-hashing passwords.

This is why it's very important to keep your system users' accounts secure and setup your files with proper permissions. As dsher points out, the only way to protect the user in this case is if your "nonce" or static salt is stored in an external file that is inaccessible to any user that is also allowed to read the source files. Personally, I'm unable to think of a way this is even possible that's unable to be determined by the cracker.

Although, I would still be a proponent of a set of nonces rather than a single nonce. If the single nonce is such a common scheme and salts are stored in the table alongside pass hashes, they have only to guess a single nonce to crack the database. However, if you're using a set of nonces that you can simply map to a particular user account (anything more complex than a single mathematical expression such as $nonceIndex = $userField % $maxNonces is probably open to exploits) then the attacker has to also correctly guess a different nonce for each account.

I'd like to point out that no system is 100% secure. The goal of internet security is to throw so many roadblocks in the path of a would-be cracker that they'd prefer to spend their time cracking a less secure website.

** edit - I should clarify, they would need to guess the single nonce if they had cracked only the database component. If they have system access as described above, it's still Game Over even if you're using a set as they have the algorithm used to determine the nonce index for each account.

[133794m3r]

Have any of you used the program there? http://www.greensql.net/

I already read the paper that was posted here about mysql injection prevention. And i'm goign to be sure to make sure that i santize all of the inputs from EVERY user, and also to make sure to follow everything that they said in that document(where ever it is now i can't link to the post since i can't remember) and make sure that it's unable to such an attack. And also of course i'm goign to make sure to not name the root account root or if mysql won't let me do such a thing, then i'll just use a string of random text atleast 32 characters long for it's password. I was thinking about using greensql simply b/c well i am human after all, and if i forget to santize the inputs one time then well it's all over. And having it there would be a nice fallback incase i forget it for one day. I've looked at the benchmarks for it, http://www.greensql.net/publications/greensql-performance-test there. And it doesn't seem to be  tooo bad of a performance drop to me atleast for the protection.

[dsheroh]

the only way to protect the user in this case is if your "nonce" or static salt is stored in an external file that is inaccessible to any user that is also allowed to read the source files. Personally, I'm unable to think of a way this is even possible that's unable to be determined by the cracker.

You couldn't do that with an interpreted language in the first place, since the user who owns the process needs to be able to both read the source (to execute it) and read the data files (so the process started by the user can access them).  In theory, you could work up something with suid to allow the program to access files the user can't (similar to /bin/passwd and /etc/shadow), but that would open a couple new cans of security worms to deal with - it's bad enough that many *nix variants (including, I believe, all Linux distros) don't allow interpreted code to run suid at all, only compiled binaries.

Although, I would still be a proponent of a set of nonces rather than a single nonce. If the single nonce is such a common scheme and salts are stored in the table alongside pass hashes, they have only to guess a single nonce to crack the database. However, if you're using a set of nonces that you can simply map to a particular user account (anything more complex than a single mathematical expression such as $nonceIndex = $userField % $maxNonces is probably open to exploits) then the attacker has to also correctly guess a different nonce for each account.

No argument on that point.  The known-plaintext attack against the nonce that I mentioned in my earlier post would, in this variation, only compromise a subset of the user database, which is a net gain.  The thing I was arguing against as pointless complexity was the idea of having rotating nonces over time rather than a fixed list of them.  (Which fails your criterion of a simple account => nonce mapping.)

I'd like to point out that no system is 100% secure. The goal of internet security is to throw so many roadblocks in the path of a would-be cracker that they'd prefer to spend their time cracking a less secure website.

You don't have to outrun the lion, you just have to outrun the guy next to you...

[JGadrow]

You couldn't do that with an interpreted language in the first place, since the user who owns the process needs to be able to both read the source (to execute it) and read the data files (so the process started by the user can access them).

Thus, why I said I couldn't think of a way it would be possible. Good to have it confirmed though. lol

The thing I was arguing against as pointless complexity was the idea of having rotating nonces over time rather than a fixed list of them.  (Which fails your criterion of a simple account => nonce mapping.)

Not really, the index could remain the same. I said nothing about what file to load that nonce from. The user's current nonce version could be stored in a database table (heck, it could be stored with the user info) and that information determines which nonce you use to hash the supplied credentials for the database check. Your code could also very simply check if the version that it just used was the current version. If not, it would pull the current version and update the user row with the new hash, also remembering to update the version of the hash that's in use.

Sure, that's probably a bit overkill. However, it would grant you a small measure of security if the cracker did not actually determine the "true" password but only a password that had the same output hash as was in the database. By changing the nonce, you've (very likely) eliminated that collision from granting access to the cracker. Thus, the cracker needs to actually determine true passwords or else their attack window is only as long as your rotation scheme allows.

If they crack the "true" password. Again, it's Game Over unless you can manage to get your users to subscribe to a rotating password scheme. But, lets face it... users are lazy! lol

You don't have to outrun the lion, you just have to outrun the guy next to you...

lol I have a D&D themed shirt that's similar (showing my geek side again):

"When you find yourself in the company of a halfling and an angry dragon. Remember, you don't need to outrun the dragon, just the halfling."