The city identity store hashes passwords and adds a unique salt per account. What security problem does salting primarily address?

Salting mixes unique, per-credential random data into the password hashing process before or as the digest is computed. Consequently, two municipal accounts that choose the identical password still produce different stored digests. That property defeats or severely weakens precomputed rainbow-table and other mass-lookup attacks that assume a password always maps to the same hash across victims. Attackers must instead attack each salted hash individually, raising the cost of offline guessing against the city identity store.

Salting does not compress hashes for faster backups; it adds uniqueness for security, often slightly increasing stored verifier size. It does not replace multifactor authentication for privileged admins—MFA addresses interactive authentication strength and phishing resistance, while salt hardens stored password verifiers. Converting hashes into reversible ciphertext for help-desk recovery would undermine one-way password storage; help desks should use reset workflows, not decryptable password vaults derived from hashes.

Exam caveat: salt uniqueness defeats precomputation; it is complementary to strong slow hashes and MFA, not a substitute for them. Operational check: confirm the municipal directory or IdP uses unique salts (or equivalent modern constructions), modern password hashing with adequate work factors, salted verifiers never reused across systems without design intent, and privileged city admins still enroll MFA beyond password hashing protections alone.