0

So, reading through this article: http://crackstation.net/hashing-security.htm it says that storing the salt is fine in plain text because it renders the lookup/rainbow tables ineffective. I get that, but why not generate the salt from the submitted password and then never store that separately either?

Something like this:

<?php
$pass = '12345';
$salt = '';
// generate the salt somehow... probably not like this
$hash1 = hash('md2',$pass);
$hash2 = hash('md4',$pass);
for($i = 0; $i < strlen($hash1); $i += 2){
  $salt .= $hash1{$i} | $hash2{$i};
}
// hash the results
$hashedPass = hash('bcrypt', $salt . $pass);
SeanJA
  • 111
  • 5

1 Answers1

8

If the salt is a function of the password, then two exact passwords will produce the same hash.

For an arbitrary hashing function H() and an arbitrary salt generation S(Password), then

H("Password_1", S("Password_1")) = H("Password_1", S("Password_1"))

While if you use a random salt generation function RS() then

H("Password_1", RS()) != H("Password_1", RS())

As an attacker, nothing can make you happier than seeing two (or more) hashes used in two (or more) different accounts. This means at least one of two things

  1. The password is weak (because two different users chose the same password), then the attacker could concentrate his computational cracking powers on those hashes.

  2. The attacker can attack two (or more) accounts using the same computational effort only once.

Adi
  • 43,808
  • 16
  • 135
  • 167
  • Nice explanation! – David Stratton Jun 03 '13 at 19:39
  • 1
    Given a large dataset, an attacker could also launch a statistical attack to recover plaintext password based on password frequency. If I have a list of thousands or millions of plaintext passwords and their relative frequencies (or simply a ranking) and a somewhat large dataset of hashed passwords (using the H(x,S(x)) method) then I can map the frequencies of a hash to the frequency of plaintext passwords. – pdubs Jun 03 '13 at 20:17
  • @pdubs Fantastic input! +1 – Adi Jun 03 '13 at 20:27