Editing Salt (cryptography) (section)

==Benefits==
To understand the difference between cracking a single password and a set of them, consider a file with users and their hashed passwords. Say the file is unsalted. Then an attacker could pick a string, call it {{code|attempt[0]}}, and then compute {{code|hash(attempt[0])}}. A user whose hash stored in the file is {{code|hash(attempt[0])}} may or may not have password {{code|attempt[0]}}. However, even if {{code|attempt[0]}} is ''not'' the user's actual password, it will be accepted as if it were, because the system can only check passwords by computing the hash of the password entered and comparing it to the hash stored in the file.  Thus, each match cracks a user password, and the chance of a match rises with the number of passwords in the file. In contrast, if salts are used, the attacker would have to compute <code>hash(attempt[0] || salt[a])</code>, compare against entry A, then <code>hash(attempt[0] || salt[b])</code>, compare against entry B, and so on. This prevents any one attempt from cracking multiple passwords, given that salt re-use is avoided.<ref>{{Cite web|title=Password Storage - OWASP Cheat Sheet Series|url=https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html|access-date=2021-03-19|website=cheatsheetseries.owasp.org}}</ref>

Salts also combat the use of precomputed tables for cracking passwords.<ref>{{cite web|url=http://kestas.kuliukas.com/RainbowTables/|title=How Rainbow Tables work|website=kestas.kuliukas.com}}</ref> Such a table might simply map common passwords to their hashes, or it might do something more complex, like store the start and end points of a set of [[Rainbow_table#Precomputed_hash_chains|precomputed hash chains]]. In either case, salting can defend against the use of precomputed tables by lengthening hashes and having them draw from larger character sets, making it less likely that the table covers the resulting hashes. In particular, a precomputed table would need to cover the string {{code|[salt + hash]}} rather than simply {{code|[hash]}}. 

The modern [[shadow password]] system, in which password hashes and other security data are stored in a non-public file, somewhat mitigates these concerns. However, they remain relevant in multi-server installations which use centralized password management systems to push passwords or password hashes to multiple systems. In such installations, the [[superuser|root]] account on each individual system may be treated as less trusted than the administrators of the centralized password system, so it remains worthwhile to ensure that the security of the password hashing algorithm, including the generation of unique salt values, is adequate.{{citation needed|date=July 2013}}

Another (lesser) benefit of a salt is as follows: two users might choose the same string as their password. Without a salt, this password would be stored as the same hash string in the password file. This would disclose the fact that the two accounts have the same password, allowing anyone who knows one of the account's passwords to access the other account. By salting the passwords with two random characters, even if two accounts use the same password, no one can discover this just by reading hashes. Salting also makes it extremely difficult to determine if a person has used the same password for multiple systems.<ref>{{Cite book |last=Stallings |first=William |title=Computer security: principles and practice |date=2015 |author2=Lawrie Brown |isbn=978-0-13-377392-7 |edition=Third |location=Boston |oclc=874734678}}</ref>