Salting

Salting in Cryptography – SSCP Study Guide

What is Salting?

Salting is a cryptographic technique in which a random, unique value (called a salt) is appended or prepended to a plaintext input—most commonly a password—before it is processed through a hashing algorithm. The resulting hash output is therefore unique even if two users choose the same password.

Why is Salting Important?

1. Defeats Rainbow Table Attacks: Rainbow tables are precomputed lookup tables that map common passwords to their hash values. Because a salt changes the input to the hash function, precomputed tables become useless unless an attacker generates a new table for every possible salt value, which is computationally infeasible.

2. Prevents Identical Hash Outputs: If two users both select the password P@ssw0rd, their stored hashes will differ because each account uses a different random salt. This means an attacker who compromises one hash cannot simply search for duplicate hashes to find accounts sharing the same password.

3. Slows Down Brute-Force and Dictionary Attacks: An attacker must factor in each unique salt when attempting to crack hashes, dramatically increasing the time and resources needed.

4. Enhances Overall Password Storage Security: Salting is considered a fundamental best practice for any system that stores password hashes.

How Does Salting Work?

Step 1: When a user creates or changes a password, the system generates a cryptographically random salt (typically 16 bytes or more).

Step 2: The salt is concatenated with the user's plaintext password. For example:
salt + password → "a8f2c9e1" + "P@ssw0rd"

Step 3: The combined value is passed through a one-way hashing algorithm (such as bcrypt, scrypt, Argon2, or PBKDF2):
Hash("a8f2c9e1P@ssw0rd") → 5f4dcc3b5aa765d61d8327deb882cf99...

Step 4: Both the salt and the resulting hash are stored together in the authentication database. The salt does not need to be kept secret—its purpose is to ensure uniqueness, not confidentiality.

Step 5: During login, the system retrieves the stored salt for that user, concatenates it with the entered password, hashes the combination, and compares the result with the stored hash. If they match, authentication succeeds.

Key Characteristics of a Good Salt

• Random: Generated using a cryptographically secure pseudo-random number generator (CSPRNG).
• Unique per user: Every account must have its own salt; reusing salts negates the benefit.
• Sufficiently long: At least 128 bits (16 bytes) is recommended to prevent exhaustive salt-space attacks.
• Stored alongside the hash: The salt is not secret; it is stored in the clear next to the hash value.

Salting vs. Peppering

A pepper is a secret value (similar to a salt) that is not stored in the database. It is typically stored in application configuration or a hardware security module. Peppering adds another layer of defense, but salting alone is the primary exam-relevant concept.

Common Hashing Algorithms Used with Salts

• bcrypt – Incorporates a salt and a configurable work factor; widely recommended.
• scrypt – Memory-hard function; resistant to hardware-based attacks.
• Argon2 – Winner of the Password Hashing Competition; modern best practice.
• PBKDF2 – Uses many iterations of a hash function (e.g., HMAC-SHA256) with a salt.

What Salting Does NOT Do

• It does not encrypt the password (hashing is one-way; encryption is reversible).
• It does not replace the need for strong passwords.
• It does not protect against keyloggers or phishing (those capture the plaintext password before hashing occurs).

---

Exam Tips: Answering Questions on Salting

1. Know the Primary Purpose: If a question asks why salting is used, the best answer typically involves preventing rainbow table attacks and ensuring identical passwords produce different hashes.

2. Salt Storage Is Not Secret: A common distractor answer will claim the salt must be encrypted or hidden. Remember: the salt is stored in plaintext alongside the hash. Its value comes from uniqueness, not secrecy.

3. Distinguish Hashing from Encryption: Exam questions may try to confuse hashing (one-way) with encryption (two-way). Salting applies to hashing, not encryption.

4. One Salt per User: If a scenario describes a system using a single global salt for all users, recognize this as a weakness. Each user account should have a unique salt.

5. Focus on the Attack It Mitigates: When you see answer options referencing rainbow tables, precomputed hash attacks, or hash collision lookups, those are strong indicators that salting is the correct countermeasure.

6. Understand the Full Process: Be prepared for scenario-based questions that walk through the authentication process. Know the order: generate salt → concatenate with password → hash → store salt and hash → verify by repeating the process at login.

7. Keyword Triggers: If an exam question mentions "random value added to a password before hashing," the answer is almost certainly salting.

8. Pair with Key Stretching: Modern best practice pairs salting with key stretching (multiple iterations). If a question asks about the most secure approach, look for answers that mention both salting and iterative hashing (e.g., bcrypt, PBKDF2).

9. Eliminate Wrong Answers Strategically: Options suggesting that salting makes passwords recoverable, that salts must be kept confidential, or that salting replaces the need for strong passwords are incorrect and can be eliminated quickly.