dragon_sa Posted February 23, 2012 Share Posted February 23, 2012 Ok here is what I am a little confused about, dealing with md5 for example - the md5 of anything generates a 32 character hash - I have a login form that supplies a user and pass to check in the database - user password stored as hash in database, so that protects visual of seeing the database, if it was somehow possible - now on submission I process that form <?php // some random salt $salt="2bhga6YHJuhyhshabshbnla;"; // user password 10 digits $pass="bLac123Kow" // hash the password $hash=md5($salt.$pass); // query db to compare user and hash $sql=mysql_query("SELECT * FROM users WHERE user='$user' AND pass='$hash'"); // process result if match login else use ip logging and ban after 5 attempts for 15mins redirect with error Ok my point of confusion is even with the hashing, the task for the hacker is only trying to find a matching or similar original password that generates the same 32 character md5 hash is it not? As every attempt made would use the same process script in my login already applying the salt for them for the comparison in a brute force attack. Lets assume the attacker has already guessed a user name and uses that for all the attempts. I am also aware that I have used a 10 character password which increases the brute force attack time. So no matter how I process the password with hashing, I have to do the same process in my login form processing to compare it to the stored hash or they wont match? Is that how it works or have I got that wrong? I am just looking for the best way to setup a login system, as I have used the above method for quite some time and not really sure if it is effective, and want to understand it better, am I using the md5 setup the best or right way? Quote Link to comment https://forums.phpfreaks.com/topic/257628-i-read-the-md5-sticky-but-process-confusion-arises/ Share on other sites More sharing options...
blacknight Posted February 23, 2012 Share Posted February 23, 2012 thats sorrect bruteforce attacks can still occure if you use a salt for hashing once you allways have to use the same salt every where that user logging in or the password will not match making useres use casps and numbers in passwords helps alot example bruting "apple" has 5 letters with 26 possabilitys for each letter 52 if upper case the more time it takes to crack a password the better but passwords can all ways be cracked or bruteforced http://www.usewisdom.com/computer/passwords.html explanes this well... most sites just use simple md5 no salt this is acceptiable but if you want more strength you can use salts... Quote Link to comment https://forums.phpfreaks.com/topic/257628-i-read-the-md5-sticky-but-process-confusion-arises/#findComment-1320441 Share on other sites More sharing options...
AyKay47 Posted February 23, 2012 Share Posted February 23, 2012 Ok my point of confusion is even with the hashing, the task for the hacker is only trying to find a matching or similar original password that generates the same 32 character md5 hash is it not? Typically, yes, a brute force approach is the best way to match a hashed string. A salt will obscure the data and make it more difficult to match. I am also aware that I have used a 10 character password which increases the brute force attack time. typically,the longer the string, the longer the brute force attack time. So no matter how I process the password with hashing, I have to do the same process in my login form processing to compare it to the stored hash or they wont match? with a hash and salt, yes. Methods of securing passwords will vary from programmer to programmer. However I think it is a pretty widespread ideology that simply md5 hashing a password is a no-no. Even prepending a string onto the password string and then md5ing the string can still be matched by a brute force attack and the algorithm can be traced. My preferred method is to use crypt. I will not ramble about this function, as there is plenty of documentation on the link I provided. But I use a tweaked version of these functions found on php.net. function makeSalt() { static $seed = "./ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"; $algo = '$2a'; $strength = '$08'; $salt = '$'; for ($i = 0; $i < 22; $i++) { $salt .= substr($seed, mt_rand(0, 63), 1); } return $algo . $strength . $salt; } function makeHash($password) { return crypt($password, makeSalt()); } function verifyHash($password, $hash) { return $hash == crypt($password, $hash); } ?> Which then means that this relation will always hold: <?php true === verifyHash($password, makeHash($password)); Quote Link to comment https://forums.phpfreaks.com/topic/257628-i-read-the-md5-sticky-but-process-confusion-arises/#findComment-1320443 Share on other sites More sharing options...
dragon_sa Posted February 23, 2012 Author Share Posted February 23, 2012 Does the crypt() method here make any difference on a brute force attack if it needs to make the inputted user password comparison at some stage? Quote Link to comment https://forums.phpfreaks.com/topic/257628-i-read-the-md5-sticky-but-process-confusion-arises/#findComment-1320477 Share on other sites More sharing options...
kicken Posted February 23, 2012 Share Posted February 23, 2012 A brute-force attack is always "possible". The way you defend against it is by limiting the number of attempts a person can make and also using an algorithm that is expensive time-wise so it takes a long time to generate a lot of tries. It's impractical to try every combination in a brute-force attack as there are simply too many and it takes too much time. This is why people will use rainbow tables and dictionary lists to try common words and variations. You defend against rainbow tables by using a random salt value. Defending against dictionary lists is just a matter of trying to get your users to use good passwords by having some rules like length and requiring numbers/mixed case. Quote Link to comment https://forums.phpfreaks.com/topic/257628-i-read-the-md5-sticky-but-process-confusion-arises/#findComment-1320488 Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.