A review of a password database shows that two users with the same password have identical stored hashes, making both accounts easy targets for precomputed rainbow table lookups. Which change addresses this weakness?
Select an answer to reveal the explanation.
Short Explanation
A salt is like adding a random secret spice to each dish, so two identical recipes come out tasting different. Same password, different hash, and suddenly your attacker's precomputed table is worthless. That's the whole game here.
Full Explanation
Salting adds a unique random value to each password before hashing and stores the salt alongside the hash. Because each user receives a different salt, identical passwords produce different hashes, so an attacker cannot see which accounts share a password and cannot use a single precomputed rainbow table for all accounts; each guess must be computed per user. Salting is usually combined with a deliberately slow password-hashing function or key stretching to further raise the cost of guessing. Encrypting the hash column with one shared key protects the hashes if the database is stolen without the key, but once decrypted, identical passwords still have identical hashes, and the key becomes a single point of failure. A shorter hash output reduces the space of possible values, increasing the chance of collisions and making attacks easier rather than harder. Base64 is a reversible encoding with no key, so storing passwords that way exposes them directly to anyone who reads the database. Exam caveat: salts are not secret; their purpose is uniqueness, not confidentiality, and they defeat precomputation rather than online guessing. Operational check: confirm each stored record has its own salt, verify the password-hashing function and work factor match current guidance, and rehash existing passwords at the next login of each user.