Jump to content

I read the md5 Sticky but.. process confusion arises


dragon_sa

Recommended Posts

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?

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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));

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.