Why do salts stop rainbow tables? [duplicate]

Question

This question already has answers here:

Closed 9 years ago.

Possible Duplicate:
How does password salt help against a rainbow table attack?

Before you mention it, I already read this question. I didn't follow.

Here's my understand of salts/rainbow tables. Please correct me where I'm wrong.

1. User inputs raw password.

2. password is concatenated with salt to give passwordsalt or saltpassword.

3. passwordsalt/saltpassword is hashed to value hash.

4. Enter hacker.

5. Hacker employs rainbow tables to reverse hash into passwordsalt/saltpassword.

6. Hacker has in hands (example) the stringletmein1horse.

Given letmein1horse, doesn't this simply mean that there are two options:

1. Password is letmein1 and salt is horse.

2. Password is horse and salt is letmein1.

So you see why I'm confused. My understand is clearly flawed, because if this was how it worked, obviously salts would be useless.

OR: Is my understanding correct, and it's the whole iteration scheme that completely undoes this obvious weakness?

Answer 1

Rainbow tables can help you go from hashes, to short sequences with limited character sets. For example, a rainbow table might support all alphanumeric sequences less than 10 characters long.

A salt is much longer and uses a wider character set. If you use a 128-bit random salt, creating a rainbow table becomes physically intractable.

Answer 2

An attacker would not be able to create a precomputed lookup table (i.e. a rainbow table) of hashed values (password + salt), because it would require a large computation for each salt. A simple dictionary attack is still very possible, although much slower since it cannot be precomputed. source