The goal of a salt is to make it so that each password must be targeted individually. The salt need not be random, only unique and sufficiently long. It is impr

The goal of a salt is to make it so that each password must be targeted individually. The salt need not be random, only unique and sufficiently long. It is impractical to precompute the hashes for (that is, have rainbow tables for) every possible salt, since rainbow tables take up a huge amount of space and take time to generate. Instead, you have to choose a specific password you want to attack and generate the table just for that password. Somebody is not just going to "have the rainbow table" for the salt G$F#V2. Your calculations are off by several orders of magnitude. Bcrypt can be customized to take more time, but a reasonable amount of time might be 0.1 seconds per password, or 10 passwords per second. Most users are already logged in, so logging in should not be a very common operation. By comparison, a $500 graphics card can hash billions of SHA1 passwords per second. So what takes 1 second to brute force with SHA1 will take 100 million times as long, or over 3 years, to brute force using bcrypt. Note that a 10 character all lowercase password has 26^10 possibilities. If we are just targeting this password it will take 19 hours at 2 billion SHA1 hashes per second (well, on average half of that, so around 10 hours), and over 447000 years at 10 bcrypt hashes per second(again, half that on average).