Question

Does using a password twice when hashing it make it safer? My example is in CodeIgniter, I striped it down to just the bare minimum. Please do not point out all the things wrong with the example, it is just an example.

<?php
function user_signup(){    // The normal way
    $this->load->database();
$new_user_insert = array(
    'password' => sha1($salt . $this->input->post('password')));

}
 function user_signup(){    // The double insert way
    $this->load->database();
$new_user_insert = array(
    'password' => sha1($this->input->post('password') . $salt . $this->input->post('password')));

}
}

EDIT:
My thought is that it would make the in put twice as long, an example (username: joe, password: 123456789). So instead of having a rainbow table with my hashed 123456789, it would be 123456789123456789. I know this is a over simplification, and the hash would look more like 01a967f5d27b9e910754729a669504a60d2aa865, but a would be hacker would need a bigger rainbow table.Please correct me if I am wrong.

Thank you in advance.

Answer 1

a would be hacker would need a bigger rainbow table

This isn’t the case if the attacker knows your strategy for hashing the password.

Suppose, for simplicity’s sake, that your password needs to be a 4-digit number. (Of course, this is generalizable to more complex passwords.) There are then 10,000 possible passwords. If you concatenate the password with itself to produce an 18-digit number, the attacker can deduce the second nine digits from the first nine: 1234salt1234 is potentially valid, but 1234salt4321 cannot be, and it would not be included in a rainbow table. The additional digits, bring a function of known information, add no additional complexity.

Adding a user-specific salt to the password as a hash defends against an attacker who can obtain the password hashes and who knows the system. In particular, the attacker knows the algorithm for hashing the user’s password. Assuming as before a four-character numeric password, such an attacker using a brute-force strategy would still need to attempt only 10,000 combinations (0000salt0000, 0001salt0001, …, 9999salt9999). The original strategy (not concatenating the password with itself) would also require 10,000 combinations (0000salt, …, 9999salt), so would be no less difficult (for practical intents).