In cryptography, a salt is random data that
is used as an additional input to a one-way
function that hashes a password or passphrase.
The primary function of salts is to defend
against dictionary attacks versus a list of
password hashes and against pre-computed rainbow
table attacks.
A new salt is randomly generated for each
password.
In a typical setting, the salt and the password
are concatenated and processed with a cryptographic
hash function, and the resulting output is
stored with the salt in a database.
Hashing allows for later authentication while
defending against compromise of the plaintext
password in the event that the database is
somehow compromised.
Cryptographic salts are broadly used in many
modern computer systems, from Unix system
credentials to Internet security.
Unix implementations
Earlier versions of Unix used a password file
to store the hashes of salted passwords.
In these older versions of Unix, the salt
was also stored in the passwd file together
with the hash of the salted password.
The password file was publicly readable for
all users of the system.
This was necessary so that user-privileged
software tools could find user names and other
information.
The security of passwords is therefore protected
only by the one-way functions used for the
purpose.
Early Unix implementations limited passwords
to 8 characters and used a 12-bit salt, which
allowed for 4,096 possible salt values.
While 12 bits was sufficient for the 1970s,
by 2005 disk storage had become inexpensive;
so much so that an attacker could pre-compute
the hashes of millions of common passwords,
including all 4,096 possible salt variations
for each password, and store the precomputed
values on a single hard drive.
An attacker with a larger budget could build
a disk farm with all 6-character passwords
and the most common 7- and 8-character passwords
stored in hashed form for all 4,096 possible
salt values.
Web application implementations
It is common for a web application to store
in a database the hash value of a user's password.
Without a salt, a successful SQL injection
attack may yield easily crackable passwords.
Because many users re-use passwords for multiple
sites, the use of a salt is an important component
of overall web application security.
Some additional references for using a salt
to secure password hashes in specific languages
can be found in the external links section
below.
Benefits
A public salt makes it more time-consuming
to crack a list of passwords.
However, it does not make dictionary attacks
harder when cracking a single password.
The attacker has access to both the hashed
password and the salt, so when running the
dictionary attack, the attacker can simply
use the known salt when attempting to crack
the password.
To understand the difference between cracking
a single password and a set of them, consider
a single password file that contains hundreds
of usernames and passwords.
Without a salt, an attacker could compute
hash(attempt[0]), and then check whether that
hash appears anywhere in the file.
The likelihood of a match, i.e. cracking one
of the passwords with that attempt, increases
with the number of passwords in the file.
If salts are present, then the attacker would
have to compute hash(salt[a] . attempt[0]),
where "." denotes concatenation, compare against
entry A, then hash(salt[b] . attempt[0]),
compare against entry B, and so on.
This defeats "reusing" hashes in attempts
to crack multiple passwords.
Salts also combat the use of rainbow tables
for cracking passwords.
A rainbow table is a large list of pre-computed
hashes for commonly used passwords.
For a password file without salts, an attacker
can go through each entry and look up the
hashed password in the rainbow table.
If the look-up is considerably faster than
the hash function, this will considerably
speed up cracking the file.
However, if the password file is salted, then
the rainbow table would have to contain "salt
. password" pre-hashed.
If the salt is long enough and sufficiently
random, this is very unlikely.
Unsalted passwords chosen by humans tend to
be vulnerable to dictionary attacks since
they have to be both short and meaningful
enough to be memorized.
Even a small dictionary has a significant
chance of cracking the most commonly used
passwords.
Since salts do not have to be memorized by
humans they can make the size of the rainbow
table required for a successful attack prohibitively
large without placing a burden on the users.
More technically, salts protect against rainbow
tables as they, in effect, extend the length
and potentially the complexity of the password.
If the rainbow tables do not have passwords
matching the length and complexity of the
salted password, then the password will not
be found.
If found, one will have to remove the salt
from the password before it can be used.
Additional benefits
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 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.
Salts also make dictionary attacks and brute-force
attacks for cracking large numbers of passwords
much slower.
Without salts, an attacker who is cracking
many passwords at the same time only needs
to hash each password guess once, and compare
it to all the hashes.
However, with salts, each password will likely
have a different salt; so each guess would
have to be hashed separately for each salt,
which is much slower since hashing is generally
computationally expensive.
Another benefit of a salt is as follows: two
users might choose the same string as their
password, or the same user might choose to
use the same password on two machines.
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,
the odds are that even if two accounts use
the same password, no one can discover this
by reading password files.
See also
Password cracking
Cryptographic nonce
Initialization vector
Padding, sometimes confused with salting
"Spice" in the Hasty Pudding cipher
Rainbow tables
References
External links
Morris, Robert; Thompson, Ken.
Password Security: A Case History.
Murray Hill, NJ, USA: Bell Laboratories. 
Wille, Christoph.
"Storing Passwords - done right!". 
Primer on Unix password structure
OWASP discussion of hashing java with salt
OWASP Cryptographic Cheat Sheet
how to encrypt user passwords
