MD5 Password

NZ_Kiwis

$UserPass = md5($UserPass);
mysqli_query ($mysqli, "INSERT INTO users (`ID`, `EmailAddress`, `UserPass`) Values('',  '$Email', '$UserPass')") or die("INSERT error  : " .  mysqli_error($mysqli));

$Email = mysql_escape_string($_POST['email']);
$UserPass = md5($_POST['password']);


$results = $mysqli->query("SELECT * FROM `users` WHERE `EmailAddress` = '$Email' AND `UserPass` = '$UserPass'") or die(mysqli_error($mysqli)); 	
$numrows = $results->num_rows;

not matter what i enter a get 0

why

NZ_Kiwis

some of my original code did not post, the furst code snippet is for when a user registers the second is when they log in.

cluelessPHP

MD5 for passwords is not secure, I wouldn't recommend using it as your only line

<?php
$username    = $_POST['username'];
$password    = $_POST['pass'];
$salt        = md5($username);
$pepper      = "72gGeeLjuZfGa/#$fCilQpPmcVKkA8r7";

$hash = hash('sha256', $salt.$password.$pepper);

mysqli_query("
    INSERT INTO users (username, password) 
    VALUES ('$username','$password')
") or die(mysql_error());
?>

<?php

$username    = $_POST['username'];
$password    = $_POST['pass'];
$salt        = md5($username);
$pepper      = "72gGeeLjuZfGa/#$fCilQpPmcVKkA8r7";

$hash = hash('sha256', $salt.$password.$pepper);

$q    = mysqli_query("
            SELECT password
            FROM users
            WHERE username = '$username'
        ") or die(mysqli_error());

if ($res  = mysqli_fetch_assoc($q)) {
    if ($res['password'] == $hash) {
        // Log In user here
    } else {
        // Wrong username or password
    }
} else {
    // User does not exist in database
}
?>

You should be able to modify this to your needs.

Weedpacket

There is a case against using "pepper" (see, for example, http://blog.ircmaxell.com/2012/04/properly-salting-passwords-case-against.html)

Note that PHP has a [man]password_hash[/man] function, which should probably be used instead of trying to make your own.

Bonesnap

Weedpacket;11049053 wrote:
There is a case against using "pepper" (see, for example, http://blog.ircmaxell.com/2012/04/properly-salting-passwords-case-against.html)

I just read through the blog post and honestly I think his arguments are all pretty weak.

His first "flaw" he even admits that it's not a very good argument against it. I would also argue that peppers aren't all that common especially when compared to the usage of salts.

His second "flaw" doesn't really make sense because you wouldn't be modifying any hashing algorithms. He mentions about combining the salt and pepper but in reality you would combine the (original) password and pepper, and send that value to the algorithm. You could also use this technique to invalidate all passwords by changing the pepper and force users to change passwords. Breached websites have to do this all the time. Without access to the source code an attacker would have no idea that a random/complicated string was being appended (or prepended, or whatever) to the users' passwords.

His third "flaw" isn't even a flaw. He's basically saying there is something else you could use that (he) believes is better. That's not a flaw. That's like saying Windows is flawed because there's Linux.

His fourth "flaw" that he believes is the biggest one is just flat out wrong. Majority of password/database breaches results in a database dump and no source code. It's pretty rare for the source code to be dumped as well. Remember all those high profile dumps with LinkedIn, eHarmony, Last.fm, Yahoo, etc. in 2012? None of them involved source code. Just passwords (and emails/user names). The only one I can think of off the top of my head was Sony, but that went waaaay beyond just source code. At that point users' passwords were the least of their concerns. Also I think maybe Gawker had source code dumped along with passwords many years ago but I don't remember for sure. In any case it's also possible that the database doesn't even reside on the same server as the application/website's source code, so...

But really just because there's the possibility that the source code could be dumped isn't a very good argument against it. It's possible someone could lift your house key off you and copy it. I don't think anyone is going to stop using those, though.

There's really not much involved in adding a pepper. It's a few lines of code and very little effort when in reality it adds an additional layer of security. It wouldn't cripple your application if you decided not to use one, either.

Also, being secure isn't always about being completely impenetrable; many times it's about being more of a hassle than the guy next to you.

Weedpacket;11049053 wrote:
Note that PHP has a [man]password_hash[/man] function, which should probably be used instead of trying to make your own.

This is still probably the best option, but you could still use a pepper with it.

laserlight

Bonesnap wrote:
His fourth "flaw" that he believes is the biggest one is just flat out wrong. Majority of password/database breaches results in a database dump and no source code. It's pretty rare for the source code to be dumped as well. Remember all those high profile dumps with LinkedIn, eHarmony, Last.fm, Yahoo, etc. in 2012? None of them involved source code. Just passwords (and emails/user names). The only one I can think of off the top of my head was Sony, but that went waaaay beyond just source code. At that point users' passwords were the least of their concerns. Also I think maybe Gawker had source code dumped along with passwords many years ago but I don't remember for sure. In any case it's also possible that the database doesn't even reside on the same server as the application/website's source code, so...

But really just because there's the possibility that the source code could be dumped isn't a very good argument against it. It's possible someone could lift your house key off you and copy it. I don't think anyone is going to stop using those, though.

Yes, the author either did not know or forgot about defense in depth, either of which does not inspire confidence in an article about security.

sneakyimp

NZ_Kiwis;11049033 wrote:

$UserPass = md5($UserPass);
mysqli_query ($mysqli, "INSERT INTO users (`ID`, `EmailAddress`, `UserPass`) Values('',  '$Email', '$UserPass')") or die("INSERT error  : " .  mysqli_error($mysqli));

$Email = mysql_escape_string($_POST['email']);
$UserPass = md5($_POST['password']);


$results = $mysqli->query("SELECT * FROM `users` WHERE `EmailAddress` = '$Email' AND `UserPass` = '$UserPass'") or die(mysqli_error($mysqli)); 	
$numrows = $results->num_rows;

not matter what i enter a get 0

why

You obviously haven't supplied all of your code so the problem could be somewhere else. For starters, you are using mysql_escape_string in the second script but I can't tell if you are in the first one or not. Also, you should not be using mysql_escape_string when you are using mysqli to perform your queries. I would try echoing the actual queries being run to make sure they are inserting/looking for the exact same thing.

Weedpacket

Well, at risk of hijacking the thread, I'll have to say that the defence in depth aspect is the strongest argument in favour of pepper; without that it's just part of a fancy salt generator. The strongest argument against it (aside from the added maintenance overhead) is the lack of serious analysis into its cryptographic effectiveness/strength (perhaps because it is not significantly more than gilding a salt lily). Thinking along those lines makes me think of having several different pepper strings and picking one at random for each hash (a "pepper grinder", if you will). During verification it would mean having to test using each pepper in turn (so don't have too many) because there's no information about which one was actually used for any given hash.

For the real issue at hand in this thread (apart from the obsolete password storage method), either not enough debugging has been done yet, or the results haven't been described.

$pepper      = "72gGeeLjuZfGa/#$fCilQpPmcVKkA8r7";

Notice: Undefined variable: fCilQpPmcVKkA8r7
🙂