1

I read from wiki:

The attacker has access to both the hashed password and the salt, so when running the dictionary attack, the attacker can simply use the known salt when attempting to crack the password.

I have two questions:

  1. Should the attacker not get the hashed (password + salt) instead?
  2. Is it true that the attacker can get the salt?
0
2

The assumption is that if the attacker can get the hash (of salt + password) then they can get the salt as well, as they're usually stored in the same location, either in a separate column in the same database table, for instance, or as a single compound value as you might see, for instance, from the *Nix crypt function.

So yes, the attacker will get bot the hash and the salt. This, however, is not a problem, as the salt is (by design) not required to be secret. Thus, the fact that it can be obtained by the attacker does not weaken the security of the system below it's designed strength.

3
  1. Obviously, preventing access by an attacker to the stored hashes is preferable. Hashes are the next line of defense after access denial fails; when the attacker dumps your database, he has to run a dictionary attack on the hash to discover the plaintext.

    What salts prevent is the use of a pre-compiled "dictionary", aka a "rainbow table". Without a salt, or with a universally-constant salt (same thing), any and all previous efforts to compute hashes can be re-used by remembering and storing the message and its hash, then simply searching for a matching hash. However, with a unique, random salt for each hash value, now no work can be reused; the message has to include that specific salt value, and it's extremely unlikely that an attacker would find a working message in a rainbow table.

  2. Yes, the attacker can get the salt. It's technically "public" information, because it must be available to any machine attempting to verify a hash. As Xander said it's usually either stored in a different column of the same database, or its prepended as a number of character-encoded bytes onto the hash digest itself.

3
  • Why can't I reuse the rainbow table? I thought it covered all the combinations of characters up to a length n? SO, should;t at some point (password + salt) and its hash exists in the rainbow table?
    – xcoder
    Feb 18 '15 at 20:06
  • "...with a universally-constant salt (same thing), any and all previous efforts to compute hashes can be re-used by remembering and storing the message and its hash..." Why? The salt, even though the same, can be sth like @!, how a pre-computed dictionary attack work in this case?
    – xcoder
    Feb 18 '15 at 20:26
  • Because if the salt value is the same for every hash in the list, it's like having more than one ticket for a drawing; a message you're hashing with that salt could be equal to any of the hash digests, and if so, you've just cracked that hash. If you want to crack another, you just pick up where you left off, because you know none of the messages you've tried have worked yet. This reduces the effective complexity of cracking hashes in the list. With unique salts, you have to focus on each individual hash to crack it, and if you want to crack more than one, you have to start over each time.
    – KeithS
    Feb 19 '15 at 15:48

Not the answer you're looking for? Browse other questions tagged or ask your own question.