Salt

When a password is stored, the system generates a random value for that specific password, combines it with the password, and runs the result through a key derivation function. The salt is stored next to the resulting hash, in the clear, because it is needed again to verify the next login. Because every password gets a different salt, two users who chose the same password end up with different stored values, and an attacker cannot crack both at once or match either against a precomputed table. That is the whole job of the salt: it removes the shortcut of precomputation and forces the attacker to attack each password individually.

The common failure is not a missing salt but a salt doing a job it was never meant to do. “Salted SHA-256” appears constantly in the systems we audit, and it is a finding: a general-purpose hash function is fast by design, so a salted fast hash still falls to a wordlist at speed. The salt only removes precomputation; what makes cracking expensive is the memory and time cost of a proper key derivation function such as Argon2id. Two more things we see: a single salt reused across every account, which restores exactly the shortcut the salt exists to remove, and a salt treated as a secret. The value that is meant to be secret and stored separately is a pepper, which is a different control.

Password storage is reviewed whenever we get code or database access, and the finding is written against the algorithm, not the salt. What we record is which function derives the key, its cost parameters, whether each hash carries its own unique salt, and whether the parameters have been raised since the system was built. A correct, unique salt sitting in front of a fast hash is still reported, because it does nothing against a brute-force attack at speed. In practice most developers should not be handling salts by hand in 2026: modern algorithms generate the salt, embed it in the stored string, and read it back on verification.