Security; md5 w/ salt in config

coldwerturkey

I know md5 alone, is strong, but still weak because of human error (short pass). So I've added a salt,

$pass = $_POST['password'];
$salt='8$&nC@bG+f_D'; //shortened 
$hash=md5($pass.$salt);

Is that enough or would it be more secure if I kept my salt in an external config file above my servers public folder?

The config file is set up exactly like so;

<?php
$DATA['hostname']='localhost';
$DATA['database']='database';
$DATA['username']='***';
$DATA['password']='***';
$DATA['salt']='8$&nC@bG+f_D'; //shortened 
?>

I had read somewhere that if the config file is set up as I did, the only way to obtain the data is to literally pull it off (ftp, server admin i mean) is that true or does it not matter where the config file (w/ database passwords) is stored on the server?

or md5(md5()), or, using random salts storing them on the db. I just don't want to be held liable for any password vulnerability, & don't know what's good enough,

(No private data (ie, phone numbers, ccard#'s) are held behind these passwords, just the passwords themselves I'm worried about)

Thanks

NogDog

The best way to protect your config file is to store it outside of the web document root directory hierarchy. For example, if your web root is "/users/coldwerturkey/public_html/", then you'd want to store it some place like "/users/coldwerturkey/includes/config.php". (Or you could be a bit sneaky and add another layer of obfuscation by calling it something like "/users/coldwerturkey/recipes/potato_soup.txt".)

Remember, though, that the single most important thing you can do is to ensure that all of your passwords to access your site (login, FTP, and database) are very strong and never given to anyone you do not 100% trust (and even then you should probably change them as soon as that other person no longer needs access). All the security steps you take to make your PHP code and user passwords secure is useless if someone can log into your site and read all your files at their leisure.

bradgrafelman

Also note:

coldwerturkey wrote:
I know md5 alone, is strong

Not really - it's actually considered rather weak nowadays, what with all of the rainbow tables and whatnot available. Consider using [man]sha1/man - it's a bit stronger.

coldwerturkey wrote:
md5(md5())

IIRC, doing something like that is only doing more harm than good as it increases the chance of a collision happening.

coldwerturkey wrote:
I just don't want to be held liable for any password vulnerability

So include a statement like that in your AUP or whatever you have.

laserlight

Are you trying to secure a password in a configuration file, or user supplied passwords in a database?

For the former, NogDog's suggestion applies. You need the password in the clear so that the script can actually use it, but you need to keep it away from prying eyes even in the event that the web server fails to parse your PHP script and serves its source code as a text file instead. If an attacker gets access to the server this password is compromised, but this would be a small problem compared to the overall damage done in such a case.

For the latter, the use of a cryptographic hash and a salt applies. The idea here is to protect your users' passwords even in the event that the server is compromised, especially since users tend to reuse their passwords. The adding of a salt does not make the password stronger, but rather slows down the attacker and thus minimises the damage done. I also think that SHA-1 is a better choice over MD5 for this purpose, though other cryptographic hash algorithms that may be supported by [man]hash/man could be even better. On the other hand, some have argued that even the use of a salt with these hash algorithms is not good enough, and suggest schemes such as this Future-Adaptable Password Scheme instead.

TeraTask

That paper seems very much like it's advocating a hash based off of Blowfish encryption with some extra stuff thrown in (I just did a quick read). Primarily this is done to address this concern:

That means passwords should not be hashed by a single function F with fixed computational cost, but rather by one of a family of functions with arbitrarily high cost.

Given that it also says

Ideally, one would like any password handling algorithm to be a strong one-way function of the password -- that is, given the algorithm's output and other inputs, an attacker should have little chance of learning even partial information she could not already have guessed about the password. Unfortunately, one-way functions are defined asymptotically with respect to their input lengths -- an attacker has negligible probability of inverting a one-way function on sufficiently large inputs, but exactly how large depends on the attacker. Because there is a fixed limit to the size of passwords users will tolerate, we need a different criterion for functions on passwords.

"An attacker has negligible probability of inverting a one-way function on sufficiently large inputs" leads me to believe that with a sufficiently long seed value which is also unique to the object being hashed, and multiple hash functions, one could achieve a fair level of security.

I always use SHA512 to hash as that seems to be the strongest from the more available hashing algos currently in use and available via hash(). Tying that in with, say, 2 or 3 other hashes would also meet the requirements proferred by them except for 1: time of overall hashing, but given that they say "It follows that the best security one can achieve is [epsilon roughly equal to |F|], where |F| is the cost in gates of implementing F.", I don't know that the number of "gates" (which they define to mean "the work invested by an attacker") would be decreased significantly.

Do you see something in that paper which I'm missing?

laserlight

"An attacker has negligible probability of inverting a one-way function on sufficiently large inputs" leads me to believe that with a sufficiently long seed value which is also unique to the object being hashed, and multiple hash functions, one could achieve a fair level of security.

I agree, though at the moment I am not convinced that there is no hidden loophole behind combining or repeatedly applying hash functions arbitrarily. For example, bradgrafelman noted that repeated application of MD5, if he remembers correctly, might do "more harm than good as it increases the chance of a collision happening". Whether this is true, and if so, still holds true if salts are involved, is something that I am not clear about.

I always use SHA512 to hash as that seems to be the strongest from the more available hashing algos currently in use and available via hash(). Tying that in with, say, 2 or 3 other hashes would also meet the requirements proferred by them except for 1: time of overall hashing, but given that they say "It follows that the best security one can achieve is [epsilon roughly equal to |F|], where |F| is the cost in gates of implementing F.", I don't know that the number of "gates" (which they define to mean "the work invested by an attacker") would be decreased significantly.

Thomas Ptacek, one of those who argue that raw hash + salt is not good enough, has pointed out in his blog entry Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes that "on modern CPUs, raw crypto building blocks like DES and MD5 can be bitsliced, vectorized, and parallelized to make password searches lightning fast". Incidentally, I got the link to the Eksblowfish paper from that blog entry.

Do you see something in that paper which I'm missing?

With respect to the Eksblowfish algorithm that that paper proposes, I think that you have missed the interesting idea of making the cost variable. As far as I can tell, that is the crux of the paper, alongside the use of the Blowfish key schedule itself.

TeraTask

Thanks. I'll look at those when it's not almost 4 in the morning.

I didn't know that repeated hashing increases the probability of a hit. In fact, the site you link to seems to suggest that repeated hashing is suggested.

I never studied the mathematics behind hashing too much in depth. This has been a great learning experience. I love when the programming side meets the math side -- I'm in heaven.

coldwerturkey

@ (post #4); I'm trying to secure the users pass on the database. The thought I had about the config file was just to keep the salt unknown (if that is a factor in solving the hash faster)

I think I'm just going to use the following

$pass = $_POST['password']; 
$salt='8$&nC@bG+f'; //shortened & stored in config file
$hash=sha1(md5($pass).$salt);

according to this guy's math, md5(md5()) is 2% stronger, so I figure sha1(md5()) has to be stronger, but than again, I have no formal education, training or knowledge of php...

TeraTask

Just don't use the seed you've just publicly announced. In the paper you reference, I would question the guy's analysis. If md5 has X number of possible values then md5(md5()) has the same number of possible values. In math, if md5(x) is a subset of Y, then md5(md5(x)) is a subset of Y. The collisions would be different, but they would still exist and in that guy's words "...and indeed when the second hashing is done the number of hash collisions is greater." Mixing hashing methods changes all of the probabilities and that's what you've done.

Far better is using a different seed for each hashed value, so if you're hashing the customer's password, then storing a seed value (say, using uniqid) along with the account information would allow for greater security: knowing one hash has no bearing on knowing another. The paper laser referred to suggests that if the same seed is used, then the mathematics behind the hack is substantially simpler.

Also, that same paper indicates that a longer seed would be more secure.

If only bcrypt were available in PHP with any degree of reliability and ease. 🙂

laserlight

The thought I had about the config file was just to keep the salt unknown (if that is a factor in solving the hash faster)

If an attacker has obtained access to your database, chances are he or she has access to your config file as well, so putting a single salt value in a config file is of no advantage to you.

I think I'm just going to use the following

I echo TeraTask's suggestion here: use a random user specific salt. Store the salt alongside the password as the salt need not be secret. When you want to authenticate the user, retrieve the salt and the password hash, use the salt to compute the hash of the given password, then compare the result with the stored password hash.

according to this guy's math, md5(md5()) is 2% stronger, so I figure sha1(md5()) has to be stronger

The 2% figure is an assumption that "the number of possible MD5(MD5(x)) hashes is 2% smaller", and thus is not about repeated application of MD5 being 2% stronger than MD5.

I have no formal education, training or knowledge of php...

The analysis is concerned with the algorithm, not the programming language.

NogDog

laserlight;10879171 wrote:
If an attacker has obtained access to your database, chances are he or she has access to your config file as well, so putting a single salt value in a config file is of no advantage to you.

But this could be extended to any hashing algorithm/process you care to implement. If the only thing hacked on your web site is the database, then all this concern over how to protect users' passwords can be of significant aid. But if the hacker has cracked your site or FTP login, then it's all academic, as the hacker will have complete access to the hashing process you are using, and will need only channel his dictionary/brute-force attack through the same process.

So perhaps the first question we need to address is, what is the likelihood that only your database will be stolen by a hacker? While I suppose it can happen, it's hard for me to imagine many ways that it could on the typical web site installation that would not involve cracking the site as a whole in the first place. If this assumption is correct, then maybe spending more time on ensuring the site does not get cracked in the first place would be a better value than spending that time on trying to create more convoluted hashing mechanisms. I don't mean to assert that this is true, only to raise the question for further discussion/analysis.

laserlight

But if the hacker has cracked your site or FTP login, then it's all academic, as the hacker will have complete access to the hashing process you are using, and will need only channel his dictionary/brute-force attack through the same process.

That is precisely the scenario that is expected. This password hashing is only designed to protect the users in the event that they reuse their passwords.

If this assumption is correct, then maybe spending more time on ensuring the site does not get cracked in the first place would be a better value than spending that time on trying to create more convoluted hashing mechanisms.

The idea is not to create more convoluted hashing mechanisms (i.e., to try and hide how the hashing is done in the first place), but to create hashing mechanisms that would slow down an attacker to the point that he or she cannot feasibly obtain likely pre-images to the hashes. This is why the salt need not be secret: ideally, knowledge of the salt would still not allow the attacker to find the pre-images he or she is looking for.