What is the impact on pre-calculated Rainbow Tables of adding multiple salts to a set of passwords?

Option A's text is truncated, but salts do not merely slow lookups within an existing rainbow table - they invalidate the entire pre-calculated table for any account using a different salt, requiring a full recomputation per unique salt.

When a salt is added to a password before hashing, any pre-computed rainbow table built without that salt becomes invalid because the resulting hash outputs differ entirely from unsalted hashes. Each distinct salt value requires its own independently computed table, multiplying the storage and processing cost required for a pre-calculation attack. The practical effect is that per-password unique salts render universal pre-calculated rainbow tables useless, since the attacker cannot reuse a single table across multiple accounts.

Salts are not reversible or strippable from a stored hash without knowing the original plaintext; the salt modifies the input fed to the hash function, so its effect cannot be algebraically removed from the output.

Properly implemented per-password salts cannot be negated on the fly by cracking tools without first knowing each account's unique salt, making pre-calculated rainbow table attacks infeasible rather than merely slightly slowed.