Salt (Cryptography)

In cryptography, a salt is a random value that is combined with a password or other secret before it is passed through a hash function or key derivation function. The salt is stored openly alongside the result. Its job is to make sure that two users with the same password end up with different stored hashes, and that an attacker cannot use tables of answers computed in advance. Salting is a standard part of how banks, payment companies, cryptocurrency exchanges and almost every online service store passwords.

A salt is not a secret and is not a key, and salted hashing is one-way, unlike encryption, which can be reversed with the right key. It is often confused with a "pepper", a separate secret value kept outside the password database, and with a nonce, a number used once in a protocol or, in mining, the value miners change while searching for a valid block. Salts belong to the wider field of cryptography and work together with slow password-hashing functions such as bcrypt, scrypt, PBKDF2 and Argon2.

Imagine a cloakroom where every coat gets a ticket stamped only with the coat's colour. Anyone who has seen a black-coat ticket once can claim every black coat. Now imagine the attendant adds a random serial number to each ticket before stamping it. Two black coats now have completely different tickets, and a forger must start from scratch for each one.

A salt is that serial number. People often choose the same passwords, such as "password123". Without a salt, all of them produce the same stored hash, so cracking one cracks them all. With a unique salt per user, each hash looks different, and an attacker has to attack each account separately.

When a user sets a password, the system generates a fresh random salt, combines it with the password and runs both through a slow function. In general form:

• $H$ is the value stored in the database.
• $\text{KDF}$ is the key derivation or password-hashing function, such as Argon2id, scrypt, bcrypt or PBKDF2.
• $s$ is the salt, a random value unique to this user.
• $c$ is the cost setting, such as an iteration count or memory size.

The system stores $s$, $c$ and $H$ together. At login it repeats the calculation with the stored salt and compares the result. Worked example of the effect: if a salt is 128 bits long, there are $2^{128}$, about $3.4 \times 10^{38}$, possible salts. An attacker who wanted a ready-made table covering a list of one million common passwords would need a separate table of a million entries for every possible salt, which is far beyond any computer, so precomputation is pointless.

• Rainbow tables. These are precomputed tables, popularised by Philippe Oechslin in 2003, that let an attacker look up the password behind an unsalted hash almost instantly. A unique salt makes each table useless.
• Identical-password detection. Without salts, anyone who reads a stolen database can see which users share a password; with salts, they cannot.
• Batch cracking. Without salts, one guess can be checked against every account at once. With salts, each guess must be recomputed per account, which multiplies the attacker's work by the number of users.

Salts do not stop an attacker from guessing one user's password slowly, and they do not protect a weak password on their own. That is why salts are combined with deliberately slow, memory-hard functions, and why services add multi-factor authentication (MFA) so that a cracked password is not enough to take over an account.

Salting dates back to Unix in the 1970s. Robert Morris and Ken Thompson described in their 1979 paper "Password Security: A Case History" how the Unix password system added a 12-bit salt to each password. Modern guidance is far stricter. NIST Special Publication 800-132 requires that the randomly generated part of a salt used with password-based key derivation be at least 128 bits, and the OWASP Password Storage Cheat Sheet recommends a unique salt per password, generated by a secure random number generator, combined with Argon2id, scrypt, bcrypt or PBKDF2.

In finance, salting is expected under information-security rules and card-industry standards for protecting stored credentials, and failures to salt passwords have featured in several high-profile data breaches, after which leaked hashes were cracked in bulk and reused in account takeover attacks.

Salts also appear in crypto. The BIP 39 standard, which turns a seed phrase into the master seed of a crypto wallet, runs the phrase through PBKDF2 with HMAC-SHA512 and 2,048 iterations, using a salt made of the word "mnemonic" followed by an optional user passphrase. The passphrase, sometimes called a "25th word", therefore acts as a salt: the same 24 words with a different passphrase produce an entirely different set of private keys. Encrypted wallet files and exchange key stores use salted key derivation in the same way, so that a stolen file cannot be unlocked with precomputed tables.

Salts are not part of the proof-of-work calculation, but similar ideas appear elsewhere. Commit-and-reveal schemes in smart contracts, for example, add a random salt to a hidden bid or vote so that other users cannot guess it by hashing likely values, a defence against front-running. Graphics processing units (GPUs) are the attacker's main tool against weak or unsalted hashes, which is why the cost setting matters as much as the salt.

• NIST SP 800-132: Recommendation for Password-Based Key Derivation
• OWASP Password Storage Cheat Sheet
• BIP 39: Mnemonic code for generating deterministic keys