Info about the recent attack

[theymos]

You can only hash one user at a time if you operate under the constraints you've outlined.

Right. Because there's a salt, so rainbow table attacks are prevented.

You said:

Gat3way detailed it fairly well, which explains why salts (when properly implemented) offer some protection against bruteforcing and, as you correctly stated, rainbow tables.  However, a properly implemented salt system increases the compute requirement for bruceforcing dramatically, slowing own the bruteforce by a factor inversely proportional to the complexity of the salt.

So you're saying that salts are helpful against attacks that do not use rainbow-table-like attacks. That is, you're saying that an attacker trying to reverse a single hash without looking at other hashes (a brute-force attack as opposed to a rainbow table attack) is worse off when there is a known salt present. This is false. In almost all password systems, salts are less than 32 characters, which does not make brute-forcing of a single hash any slower. If you're trying to slow down brute-forcing, you typically increase the number of hash iterations, which doesn't require you to store more data.

[Xenland]

You can only hash one user at a time if you operate under the constraints you've outlined.

Right. Because there's a salt, so rainbow table attacks are prevented.

You said:

Gat3way detailed it fairly well, which explains why salts (when properly implemented) offer some protection against bruteforcing and, as you correctly stated, rainbow tables.  However, a properly implemented salt system increases the compute requirement for bruceforcing dramatically, slowing own the bruteforce by a factor inversely proportional to the complexity of the salt.

So you're saying that salts are helpful against attacks that do not use rainbow-table-like attacks. That is, you're saying that an attacker trying to reverse a single hash without looking at other hashes (a brute-force attack as opposed to a rainbow table attack) is worse off when there is a known salt present. This is false. In almost all password systems, salts are less than 32 characters, which does not make brute-forcing of a single hash any slower. If you're trying to slow down brute-forcing, you typically increase the number of hash iterations, which doesn't require you to store more data.

To everyone that thought i didn't know anything about salts....
Didn't I just say something this earlier about a page back?

But "noooo!!!" everyone was just thinking I was just putting sea-salt on meh hardware encryption function. LOL

Theymos YTMND

[Inaba]

You can only hash one user at a time if you operate under the constraints you've outlined.

Right. Because there's a salt, so rainbow table attacks are prevented.

Stop cherry picking your argument and address the matter at hand.  Yes, brute forcing one user at a time with or without a salt would take the same amount of time.  That is NOT a realistic scenario in the case of a database being compromised.  Once again, you can take an outlying case and make it say anything you want.  We aren't talking about tailor made cases to fit your conjecture.

You said:

Gat3way detailed it fairly well, which explains why salts (when properly implemented) offer some protection against bruteforcing and, as you correctly stated, rainbow tables.  However, a properly implemented salt system increases the compute requirement for bruceforcing dramatically, slowing own the bruteforce by a factor inversely proportional to the complexity of the salt.

So you're saying that salts are helpful against attacks that do not use rainbow-table-like attacks. That is, you're saying that an attacker trying to reverse a single hash without looking at other hashes (a brute-force attack as opposed to a rainbow table attack) is worse off when there is a known salt present. This is false. In almost all password systems, salts are less than 32 characters, which does not make brute-forcing of a single hash any slower. If you're trying to slow down brute-forcing, you typically increase the number of hash iterations, which doesn't require you to store more data.

I am not saying that.  I said NOTHING like that.  In fact, I said EXACTLY THE OPPOSITE.  Re-read what I wrote.

A realistic scenario is an attacker brute forcing an entire (or large subset of the entire) user table of a database.  Trying to brute force a single user without knowing the strength of the underlying password is just dumb.  Unless you need access to a specific user for a specific purpose, you are going to attack the whole database to get at the weakest passwords as quickly as possible.

This is where a properly implemented salt system protects you, and protects you fairly well, from a brute force attack.  

Broken salt implementation with no protection:

In a static salt (or no salt) situation (both being broken implementations of a salting mechanism), the attacker has already precomputed the salt and then compares the hashes + salt.  Ok, no advantage there.  Duh!  

1 try = 1 cycle

Properly implemented salt:

Random salt.  The attacker can not pre-compute the salt, because it's different for every user.

1 cycle = gather salt into memory
1 cycle = compute salt
1 cycle = compare salt + password hash

1 try = 3 cycles.  Ta-da!  You've just increased the time it takes to brute force a dataset by 3x.

With some nifty coding, you might be able to combine two of those steps.  You've still DOUBLED the time it takes to brute force a dataset.

I would say a 2 - 3x increase in brute force time is some hefty protection, personally.  You can disagree all you want, but the fact remains that properly implementing salt is a first line defense against brute forcing and when properly implemented is going to thwart all but the most determined crackers.  A static salt is fairly worthless for anything but thwarting a rainbow table, so quit holding up static salts as your pivotal argument, since that is not what we are talking about.   We are talking about properly implemented salting mechanisms.  Static salts are not properly implemented.

PS -

I forgot to address this:

In almost all password systems, salts are less than 32 characters, which does not make brute-forcing of a single hash any slower. If you're trying to slow down brute-forcing, you typically increase the number of hash iterations, which doesn't require you to store more data.

So again, you are holding up some sort of broken password system as an example of why password systems don't work?  I don't understand your chain of logic.  What properly implemented salt system would use a short salt, besides maybe crypt?  But, by your logic, then a > 32 character salt would offer protection?  That being the case, you've just agreed with everything I've been saying and invalidated your entire argument.

[terrytibbs]

Man, theymos,
You're really good at jumping around the elephant in the room.

Yours Truly,
Terry.

[BCEmporium]

Properly implemented salt:

Random salt.  The attacker can not pre-compute the salt, because it's different for every user.

1 cycle = gather salt into memory
1 cycle = compute salt
1 cycle = compare salt + password hash

1 try = 3 cycles.  Ta-da!  You've just increased the time it takes to brute force a dataset by 3x.

Compute salt?!  
And you will salt the salt? Or it's a plain hash?  

Or your idea is for have some sort of hidden function that will render salt's value?

[mizerydearia]

Theymos YTMND

Someone should post something (worthy) at http://theymos.ytmnd.com/

[gat3way]

Just want to point out some things.

First off it's incorrect that candidates of length <=64 bytes take the same time to hash. The "boundary" in question (after which you calculate another compression function for the padding) is 55. Remember you need to add a 1 bit which would overwrite the last 8 length bytes.

Also depending on implementation, calculating hash of a 4-byte candidate might be faster than calculating say 32-byte candidate hash. That's because there is a common optimization that can be done: if w

• is always zero, then you can skip some of the ALU operations regarding it. That's because X ^0 = X and X+0=X and X|0=X and so on.

Key stretching (e.g PBKDF or using phpass) is the common way to increase security. However that comes at a cost. Large forums with many users and lots of authentication attempts would consume a lot of CPU resources.

[defxor]

To everyone that thought i didn't know anything about salts....
Didn't I just say something this earlier about a page back?

No.

I still don't get why people believe salt is about increasing the difficulty in brute forcing. While it may be a side effect depending on how it's implemented, the main purpose is in making rainbow tables inefficient.

Yes, brute forcing one user at a time with or without a salt would take the same amount of time.

Exactly, but it has to be explained here since quite a few seem to believe otherwise.

Properly implemented salt:

Random salt.  The attacker can not pre-compute the salt, because it's different for every user.

Random vs the username, as was the case here, then? Are you trying to claim that using the username as salt makes it static over the whole database??

If not, the difference between random and username becomes slim. This whole discussion began with self-appointed security experts claiming there was something inherently stupid in using the username as salt.

[BCEmporium]

And this keeps going around...
Anyone mind to explain WTF is a "random salt" in a sense it needs to be computed?!

Something like:

Code:

<?php
$chars = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
$charsToUse = mt_rand(8,25);
$salt = "";
for($l = 0; $l < $carsToUse; $l++){
    $char = mt_rand(0,strlen($chars)-1);
    $salt .= $chars[$char];
}
md5($pass,$salt);
?>

?!
Sounds nice? Am I listening a "security bullshitter" about the MD5? Rest assure! This function is so damn secure that no one will be able to decrypt it, even if it's MD5... even if brutteforced all it can renders is something out of a collision, not by any chance your actual password.

A small glitch, as we don't store the salt anywhere and it is plainly random, there's no way for anyone to log in. A small detail, but... hey... it's secure.  

[Inaba]

Not quite.  I should have been more specific.  

A different salt is used for each user, and it might as well be random since it's completely arbitrary.  You have to gather the unique salt into a variable, pass it and the password candidate along to the hashing function, compare the hash result.  With a static salt, you do not have to gather the salt and you can have your comparison routine just run that salt against the password hash.

When using the username, the username is already collected and ready to go as well, so using that is slightly less secure (is it a meaningful difference?  I dunno, never really ... ahem ... hashed it out).  

You have to store the random salt, you can't just pick one at random and hope for the best... but I assume you were being facetious in regards to that.

[BCEmporium]

Inaba,

The only way to do that by not storing the generated salt is by creating a function sort of:

Code:

<?php
function computeSalt($var_to_use_as_ground,$site_secret = "akljhe34907##!@3hjd"){
  $pw_pointer = 0;
  $salt = "";
   for($l = 0; $l < strlen($var_to_use_as_ground); $l++){
     if($pw_pointer >= strlen($site_secret)) $pw_pointer = 0;
     $salt .= $var_to_use_as_ground[$l] ^ $site_secret[$pw_pointer];
     $pw_pointer++;
  }
  return $salt;
}


//Example:
$pw = md5($receivedPwd,computeSalt($user['username'])); //be sure to use the username as in the database to not make it case-sensitive on login
?>

It had some entropy to the salt, as the only way to get the salt is by getting not only the database but the code itself also.
Nevertheless you won't be getting much, as within several samples the attacker would have enough to dump the xored var value.

[TiagoTiago]

I didn't see an answer so i'll repeat my question, would using a triple SHA512 hash of the username instead of the plain username be of any help?

[BCEmporium]

I didn't see an answer so i'll repeat my question, would using a triple SHA512 hash of the username instead of the plain username be of any help?

As we say in portuguese: "Nim" (mix não [no] and sim [yes])

It would be better to input a random number of turns instead of fixed 3, let's say 3~6:

Code:

<?php
function genSalt($username){
   $rounds = mt_rand(3,6);
   $salt = $username;
   for($l = 0; $l < $rounds; $l++){
     $salt = hash("sha512",$salt);
  }
  return $salt;
}
function checkPass($username,$givenpass,$hashpass){
   $pointer = 0; 
   $salt = $username;
   for($l = 0; $l < 6; $l++){
      $salt = hash("sha512",$salt);
       $pointer++;
     if($pointer > 3){
        $test = hash("sha512",$givenpass.$salt);
        if($test == $hashpass) return true;
     }
  }
  return false;
}
?>

[Inaba]

Inaba,

The only way to do that by not storing the generated salt is by creating a function sort of:

Code:

<?php
function computeSalt($var_to_use_as_ground,$site_secret = "akljhe34907##!@3hjd"){
  $pw_pointer = 0;
  $salt = "";
   for($l = 0; $l < strlen($var_to_use_as_ground); $l++){
     if($pw_pointer >= strlen($site_secret)) $pw_pointer = 0;
     $salt .= $var_to_use_as_ground[$l] ^ $site_secret[$pw_pointer];
     $pw_pointer++;
  }
  return $salt;
}


//Example:
$pw = md5($receivedPwd,computeSalt($user['username'])); //be sure to use the username as in the database to not make it case-sensitive on login
?>

It had some entropy to the salt, as the only way to get the salt is by getting not only the database but the code itself also.
Nevertheless you won't be getting much, as within several samples the attacker would have enough to dump the xored var value.

I'm not sure what you're getting at, but I don't disagree with what you've said.  Although we are veering further away from the topic at hand.  Are you posing a question or other interrogative or just commenting?

[BCEmporium]

I'm not sure what you're getting at, but I don't disagree with what you've said.  Although we are veering further away from the topic at hand.  Are you posing a question or other interrogative or just commenting?

I'm checking and demonstrating in terms of real code what you are discussing about; Salt generation.

In fact that $algorithm$salt$hash of crypt
the hash:salt of many systems
is a handicap on encryption.

But what resembles to be the best solution on this on-demand generated salt with Open Source software would be to create a salt class with different approaches and let the site owner to select which to use within config. This way an attacker would have to guess first which salting method was used before attempt to attack, and within the availabilities to generate the salt and input; xored strings, substring of hashes, multiple round sha hashing, bitwise etc... this would may means he would grow old before achieve something, even to the weakest of passwords.

[defxor]

would have to guess first which salting method was used

http://en.wikipedia.org/wiki/Security_through_obscurity

There's no reason to make the salt a part of the complexity of brute forcing passwords. Educate the users instead. "Password strength" indicators are one of several good ways of doing that.

[BCEmporium]

Why everyone comes with "security by obscurity" without even KNOW what that stands for?!

In Open Source NOTHING is "obscure", it's a class with several flavors, creating entropy, not "obscurity".

Educate the users instead.

This is what I call "Fascistly Imposed Security".

We don't need no education
We dont need no thought control
No dark sarcasm in the classroom
Teachers leave them kids alone
Hey! Teachers! Leave them kids alone!

[defxor]

Why everyone comes with "security by obscurity" without even KNOW what that stands for?!

In Open Source NOTHING is "obscure", it's a class with several flavors, creating entropy, not "obscurity".

Feel free to write coherent posts. Either the attacker has to guess (obscurity) or not. In any case, you're completely missing the point of salt if you feel that's a suitable place in a crypto system to add stronger complexity.

[BCEmporium]

In passwords the attacker is attempting to «GUESS» the password. You may ADD OR REMOVE walls of his path, ENTROPY.

Such system will ADD WALLS for him to break before «GUESS» what we wants to get.

Salt alone inputs a "NO PRE-COMPUTED HASHES" wall, but it's normally plain text on itself. Your objection is like saying that ADD A WALL is wrong because you think of it to be "obscure".

[defxor]

You may ADD OR REMOVE walls of his path

Yes, that's the "obscurity" part of your reasoning. It doesn't provide any added level of (real) security. When designing a security system all forms of added levels of complexity are risks where there might be edge cases you haven't thought about. You want as few implementation parts as possible, while still giving you a provable level of security.