The password for salts. Am I doing it right?

Question

I thought that maybe my login system is not as secure as I thought. So, firstly, I will tell you, in words, what I am doing.

When a user logs in, a 16 character salt is generated. I store the salt in the database in a field called "salt", I store the hashed password + salt (they are hashed together hash("sha256", $salt.$password); ) in a field called "password"

When a user tries to log in, I take the password field and the salt field from the database, as well as several other things.

To check if they entered their password correctly, I do the following:

 $hashed = hash("sha256", $row['salt'].$pass); if ($row['password'] == $hashed) { //success 

($ row is a selection from the database. $ row ['salt'] is the salt in the database, $ pass is the password entered, and $ row ["password"] is the hashed pass + salt in the database)

I thought, and it seems to me that my salt offers few (or none at all) security benefits. My question for all of you is this: does my method offer additional protection (or does it even protect all this?)

Also, I have a second question. I want to verify that this "check login" script cannot be faked / tricked into gaining access to a user account without their password.

 session_start(); require_once 'db_connect.php'; //If the session variable "id" isn't set (ie they aren't logged in) if (!isset($_SESSION['id'])) { //Check if they wanted to be "remembered" (so they have 2 cookies if (isset($_COOKIE['rem_user']) && isset($_COOKIE['rem_pass'])) { $query = "SELECT id, password, auth, email, username FROM users WHERE username='".$_COOKIE['rem_user']."' AND active IS NULL" $res = mysql_query( $query ); if (mysql_num_rows($res) == 1) { $row = mysql_fetch_array($res); // If the "remember me" cookie containing their password // is equal to the one in the database, log them back in. if ($_COOKIE['rem_pass'] == $row['password']) { $_SESSION['id'] = $row['id']; $_SESSION['username'] = $row['username']; $_SESSION['auth'] = $row['auth']; $_SESSION['email'] = $row['email']; $logged_in = 1; } } } else $logged_in = 0; } else //Since the session variable "id" WAS set, they ARE logged in. $logged_in = 1; 

I would think that the only way to log in is ...

• To trick a session variable that I don't think is possible without access to the server.
• Cheat the cookie with an encrypted password + salt, which, in my opinion, is almost impossible without access to the database.

Feedback will be appreciated. I want my system to be safe. :)

Thanks!

Answer 1

Well, here it is ... not roll safety. Here are some of the problems described above:

• The hashed password is stored as a cookie. THIS IS NOT DIFFERENT THEN STORING / VIEWING PASSWORD-TEXT PASSWORD , since it is checked as is without a hash function.

• A cookie is an SQL injection attack vector.

• Uses SHX for hashing. (Use bcrypt, scrypt, hmac, etc.)

And then I stopped looking. # 1 indicates that this should be left in an existing verified / verified library.

Answer 2

Use hash_hmac

I use it like this: hash_hmac ($ algo, $ password. $ Salt, $ siteKey);

Even if an attacker gets into your database, they will need your sitekey to work with brute force successfully, although I will not comment on the collisions. Choose your algo / poison .: D

Answer 3

Does salting provide extra protection? Yes. If the hash is compromised, you need more resources to crack the password, because salt adds many combinations. So now you cannot use the old traditional rainbow table attack. Where to store salt is another question. How will a hash be normally found by a hacker? By compromising the database. If the database is compromised, then it will also have salt, which will make salting less effective. But if the salt is hardcoded in a script, compromising the database will have no effect. Therefore, I would strongly consider hard salt in a script or using two salts - hardcoded or in a database.

Second question. Do not store password in cookies. You can easily fake them (even in Chrome’s advanced settings). Or steal them (e.g. XSS vulnerability). Keep them in a session.