Salt Encryption

Ran into encrypting using Salt in one of my other posts.

I read up on it but some of the advise is quite conflicting.

Salt is a solid encryption method, so what would be the best way to use it?

Some say have 1 default Salt key others say have individual random Salt keys for each user (if using this for a login script for example).

So if I had 1 default Salt key, I'd have something like:

$salt = SHA-256(sha256$efwef£$£$wgrg$e6b766ba2cdcbbc93e2625a31eee8a8a0fd058a82c74712c1e8d5b3833d9cfa9);
 
$encryptedpassword=crypt($password,$salt);

PHP:

But is this secure enough? Would it be better practice to generate a random Salt key when the user signs up and insert the Salt key into the user table and run a check upon login similar to:

$sth = $dbconn->prepare("SELECT salt,password FROM users WHERE username = :username");
 
$params = array("username" => $_POST["username"]);
$sth->execute($params);
 
    while ($row = $sth->fetch()) {
 
    $salt = $row[salt];
   
    $password = crypt($_POST[password],$salt);
 
    if ($password == $row[password]){
    //Passwords match
    }
    else {
    //Passwords do not match
    }

PHP:

What would be the best way to do this?

 

Including the salt in the database is more dangerous than simply defining it as a CONSTANT in your PHP code - the reason you ask? Because if your database becomes compromised, salt keys are open along-side with encrypted passwords, making it extremely easy for your hacker to decrypt - you'll have a better chance if hiding it in the actual PHP code - because either way, if they get your code, they have your site.

Personally, when handling passwords, I just md5 hash them and do a comparison in an if statement. There's no way to decrypt other than brute-force methods, and I think it's a fail-safe secure method for any website.

 

I really don't recall all the research I did when I looked into this but the answers that stick in my mind are that md5 is good enough for most and constant salt takes care of the needs of most of the rest of us. How much security do you really need? And at what price?

The salt being in the DB has been mentioned as a potential problem other places. I think encrypting the salt before storage was an option.

You probably don't need more than md5 unless you are protecting money.

 

If you want a random salt for each user, use the reversed login as the salt. (And sha256 is much more secure than md5.)

 

This is where you can get creative. I typically prefer having a salt in the database alongside the user, and a salt stored/calculated by the server/filesystem. You don't have to plug the salt in the database straight in to the encryption method. i.e. instead of just doing something like:

$password = sha1($user['password'] . sha1($user['salt_RNDKEY']) . CONSTANT_SALT)

PHP:

You can do something like:

$password = sha1($user['password'] . sha1(hashSalt($user['salt_RNDKEY'])) . CONSTANT_SALT);

PHP:

If you obfuscated the hashSalt() method, then all of a sudden you present a scenario where the user has to retrieve both the password and the salt (of which he has to find to some extent the db schema of the users table), find the value of the CONSTANT_SALT (which should be out of a web accessible directory, so essentially gain access to the filesystem), and the find/deobfuscate the hashSalt() method (which again should be out of the web accessible forum). While you could argue that it's to some extent security through obscurity, such a technique has never yet failed me on a single small-medium website.

 

This sounds like a great method. How I've currently set it up is to create a microtime key upon user signup, convert that to MD5 and use that as the users salt key. Would this be secure enough or would you recommend converting the microtime to SHA1?

Also, having a constant salt key, the main issue with it would be it remaining the same. Is there anything you can think of whereby both the constant and users salt key can be automatically changed over a period of time? I think this would greater enhance the security.

 

Pretty much that's all you can do -- the moment you are storing anything like a SALT in the database OR in the code, it's no more or less secure than a flat hash...

But I'd use SHA512 -- MD5 is a little too simple these days... Also, I wouldn't even do an if statement since my rule is NEVER have any query return the password value... Instead you send the password TO the mySQL to check it.

if you've stored them as sha512, your validation would just be:

COUNT (*) FROM users
WHERE id = :id
AND password = :password

Code (markup):

Plugging in assword from the execute or bindparam like a good little doobie. That way information travel is one direction only. I've seen a LOT of people pull the password as part of the user info -- something I would never do.

 

That's not true at all. Even if you store a salt in the database, they:

1. Have to somehow fetch it (depending on the type of exploit this may not be possible)
2. Determine what encryption method you're using to encrypt it (which they can either guess or they'd have to somehow gain access to your code).

Storing it on the filesystem means they have to gain access not only to your database, but file system as well. If you store it in a directory which isn't accessible to the web, it means they have to compromise your server.

Saying you shouldn't salt is ridiculous.

 

Nice sharing guys.

I used the following method to encrypt most of my application password:

$password = hash_hmac('md5', $_POST['password'], $salt);

Code (markup):

What do you think about it? I think it is good enough for small size website?

 

I would say no, but that's because MD5 has been cracked wide open, has a relatively small result set you can use google to rainbow table for you, and lacks sufficient entropy... even with salting it.

I suggest upping that from MD5 to something a bit more robust like SHA512 or whirlpool. As I said in another thread: "As hash goes MD5 is mersh, sha512 is Maui Wowie, and Whirlpool is Alaskan Thunderfu..."

But unlike that type of hash, there's no reason you can't afford the dank apart from encoding time -- if that's really an issue SHA256 is a nice speedy middle-ground.

 

There is a lot of bad information in this thread so I hope the OP is able to read the post above and this post.

Firstly on the use of MD5 and why not to use it: https://en.wikipedia.org/wiki/Md5#Security

Here's my collection of stack overflow questions on the subject that are well worth a read for those rolling their own password handling code:

• http://stackoverflow.com/questions/549/the-definitive-guide-to-forms-based-website-authentication
• http://stackoverflow.com/questions/4795385/how-do-you-use-bcrypt-for-hashing-passwords-in-php
• http://stackoverflow.com/questions/1561174/sha512-vs-blowfish-and-bcrypt/1561245#1561245
• http://stackoverflow.com/questions/1645161/salt-generation-and-open-source-software/1645190#1645190

That second link talks about using a hashing method best suited for passwords. BCrypt belongs to a collection of hashes oriented to hashing passwords. They are designed to actually take a large amount of resources to hash, to protect against offline brute force attacks.

In regards to using a salt, unlike what someone mentioned above, it is expected that you store a unique salt in a one-to-one relationship with the password hash. Its point is to stop someone computing a rainbow table against the hashing method that you are using, it is trivial for them to do so if you use (and they find) the same salt used in every hash, but they would have to make a rainbow table for each different salt if you do it properly, defeating the point of that attack.