4

Sorry if this is a stupid question, I just want to know: what is the point with the salt in bcrypt? I mean, if you have the following code for creating a hash from a password:

function generateSalt() {
$salt = '$2a$13$';
$salt = $salt . '1111111111111111111111';
return $salt;
}

function generateHash($salt, $password) {
$hash = crypt($password, $salt);

return $hash;
}

$salt = generateSalt();

$providedPassword = generateHash($salt, rand(3,29));

echo $providedPassword;

The above outputs for example:

$2a$13$111111111111111111111uDdpsIcwCVOwEyNueskskXkniY5206fW

$2a$13$111111111111111111111udcvrNt9quPukFRl8./jXRzDGfE9lw0W

So you can clearly see where the salt ends, and if someone gets the database there's not point with the salt, since they just can remove the salt-part and search for just the hashed password. So, am I using bcrypt wrong? (the static salt was just to show where it appears in my hashes), or is there a reason with this?

sinelaw
  • 16,205
  • 3
  • 49
  • 80
DannyCruzeira
  • 564
  • 1
  • 6
  • 19

2 Answers2

4

The idea behind a salt is that even if two inputs are the same, the hash will not be identical as long as a different salt is used every time.

For example, many users pick the same password. If you just store the hash of the password, the database will contain many identical hashes - so that if an attacker finds the password just once, he can then use it for all those users easily. However, if the password is hashed with a different salt value for each user, the attacker will have to crack each and every hash stored in the store.

I'm not sure what's that code you're using (what's that crypt function?), but it's ok if it prepends the salt value to the actual hash as long as the hash itself is also calculated using the salt. You're going to need to store the original salt anyway to verify that a new input (password) matches the stored hash. However, as long as you change the salt values between every hash usage, there's no easy way to glean information about the original input.

sinelaw
  • 16,205
  • 3
  • 49
  • 80
  • I showed the code in my question, and I got the code from this site http://www.nathandavison.com/posts/view/13/php-bcrypt-hash-a-password-with-a-logical-salt Maybe I'm implementing it wrong, because the salt ends up just in beginning of the hash before "$2a$13$" – DannyCruzeira Oct 23 '12 at 19:14
  • The salt must be randomly generated for each password. Having a fixed salt for all passwords is pointless. The code you're using generates a fixed salt. – Cameron Skinner Oct 23 '12 at 19:15
  • I know, but what I wanted to show was that the salt ends up not mixed together with the value being hashed, just in the beginning as it was created. Am I making sense? haha – DannyCruzeira Oct 23 '12 at 19:16
  • 1
    The `crypt($password, $salt)` part means that the generated hash includes the salt. When you store the salt + hash in the database it's OK to just concatenate them. The salt is not secret (nor is the hash, for that matter). – Cameron Skinner Oct 23 '12 at 19:17
  • Do you mean that the hash includes the salt in the beginning as I showed and in the actual hash after "$2a$13$"? – DannyCruzeira Oct 23 '12 at 19:21
  • @DannyCruzeira: If the salt affects the actual hash and is *also* concatenated to it, it's fine. If it is simply concatenated, there's no point in the salt. – sinelaw Oct 23 '12 at 19:23
  • I'm affraid I don't quite understand you, sinelaw. If I use the code that I have, the salt will just be included in the beginning and not hashed together with the password? – DannyCruzeira Oct 23 '12 at 19:36
  • @DannyCruzeira, take a look at this related answer: http://stackoverflow.com/a/6337021/562906 – sinelaw Oct 23 '12 at 20:17
0

Salting a hash is a means to strengthen the hash against attacks that might allow the hash to be reversed into its original value, while the hash is being sent between hosts online. in that scenario, an eavesdropper could capture the hash, but without a knowledge of the salt value, would never be able to reverse the hash regardless of technique.

Frank Thomas
  • 2,434
  • 1
  • 17
  • 28
  • But is the salt just included separate from the actual hash in the beginning as I showed, or is the password hashed together with the salt? – DannyCruzeira Oct 23 '12 at 19:08
  • 2
    @FrankThomas: That's not entirely correct. The salt isn't really there to strengthen the hash, it's to make precomputation attacks infeasible. Basically, it prevents "rainbow table" attacks, and protects users that happen to use the same password. It protects passwords that are stored. SSL is usually used to protect information on the wire. – Cameron Skinner Oct 23 '12 at 19:21