Read the original article here.

---

The Forbidden Code: Underground Programming Techniques They Won’t Teach You in School

Chapter: Guarding the Gates - Advanced Password Security with Salts

Welcome, fellow explorers of the digital underbelly. In the world of software development, particularly where secrets are kept and guarded, there are fundamental techniques that separate the truly secure systems from the vulnerable ones. While academic settings might touch upon cryptography, they often fail to instill the critical practical knowledge needed to build defenses that withstand real-world attacks. This chapter dives deep into one such technique – salting – a seemingly simple concept with profound implications for securing passwords, a common entry point for adversaries.

What is a Salt? The Secret Ingredient

At its core, a salt is a piece of random data. But not just any random data – it's a vital, unpredictable ingredient mixed into the data you're trying to protect before you apply a cryptographic hash function to it. Think of it as adding a unique, secret flavor to your password stew before you cook it down into an irreversible hash.

Definition: Salt (Cryptographic) In the context of cryptography, a salt is a piece of random, unique data added to an input, typically a password or passphrase, before it is hashed using a one-way cryptographic hash function. Its primary purpose is to make precomputed attacks (like rainbow tables) vastly more difficult and to ensure that identical inputs produce different hash outputs.

This might sound simple, but its power is immense, especially against common cracking techniques.

The Problem: Plain Hash Storage - An Open Door

Imagine a system storing passwords without any protective measures. When a user signs up, their password (let's say "password123") is fed into a cryptographic hash function (like SHA-256). The resulting hash value is then stored in the database.

User: Alice
Password: password123
Hash: 5e884898da28047151d0e56f8dc6292773603d0d6aabcffcb... (example SHA-256)

Now, consider another user, Bob, who unfortunately chose the exact same password:

User: Bob
Password: password123
Hash: 5e884898da28047151d0e56f8dc6292773603d0d6aabcffcb... (same hash!)

This is a critical vulnerability. An attacker who gains access to this database of hashes faces two major issues (from their perspective):

1. Identical Passwords == Identical Hashes: As seen above, any user with the same password will have the exact same hash stored. If an attacker cracks one hash, they instantly know the password for every user with that hash. This is a common scenario, as users frequently choose weak or common passwords.
2. Precomputed Tables (Rainbow Tables): Attackers can build massive databases containing precomputed hashes for common passwords or password patterns.

Definition: Rainbow Table A rainbow table is a precomputed table used to reverse cryptographic hash functions, typically for cracking passwords. Instead of brute-forcing every possible password guess one by one and hashing it in real-time, an attacker can simply look up a target hash in the rainbow table to find the original password (or a different password that produces the same hash).

If an attacker gets your database and sees the hash 5e884898da28047151d0e56f8dc6292773603d0d6aabcffcb..., they can look it up in their rainbow table. If they find an entry for this hash, they know the corresponding password ("password123" in this case). They've potentially cracked not just Alice's password, but Bob's, Carol's, David's, and everyone else who used "password123". This is incredibly efficient for the attacker and devastating for security.

The Solution: Salting - Adding Randomness to the Mix

Salting directly addresses these problems. Instead of just hashing the password, we generate a unique, random salt for each password and combine it with the password before hashing.

Here's the process:

1. When a user signs up or changes their password, generate a unique, random salt.
2. Combine the password and the salt (typically by concatenating them).
3. Hash the combined string (password + salt) using a strong cryptographic hash function.
4. Store the salt and the hash in the database. The salt is stored in plain text; it doesn't need to be secret.

Let's revisit Alice and Bob with salting:

User: Alice
Password: password123
Generated Salt for Alice: abcdefg (example random string)
Combined: password123abcdefg
Hashed Combined: hash(password123abcdefg) -> h1
Database Storage: Salt: abcdefg, Hash: h1

User: Bob
Password: password123
Generated Salt for Bob: hijklmn (example *different* random string)
Combined: password123hijklmn
Hashed Combined: hash(password123hijklmn) -> h2
Database Storage: Salt: hijklmn, Hash: h2

Notice a few things:

• Even though Alice and Bob used the same password ("password123"), their combined inputs are different (password123abcdefg vs. password123hijklmn).
• Consequently, the resulting hashes (h1 and h2) are completely different. There is no visual clue in the database that Alice and Bob used the same original password.

Verifying a Password with Salt

When Alice tries to log in and enters "password123", the system performs the following steps:

1. It retrieves Alice's salt (abcdefg) and stored hash (h1) from the database using her username.
2. It takes the password she entered ("password123") and combines it with her retrieved salt (password123abcdefg).
3. It hashes this combined string: hash(password123abcdefg).
4. It compares this newly computed hash to the hash stored in the database (h1).
5. If they match, the password is correct. If not, it's incorrect.

This process works because the salt is stored alongside the hash. We don't need to guess the salt; we know it for that specific user.

Why Salting is Your First Line of Defense

Salting provides crucial security benefits:

1. Defeating Rainbow Tables: This is the primary goal. A rainbow table works by precomputing hashes for common passwords. With salting, the attacker doesn't need a table of hash(password), but a table of hash(password || salt). Since each user has a unique salt, the attacker would need a separate rainbow table entry for password123 combined with every possible salt value. If the salt is long and random, the number of possible salt values is astronomical. Precomputing a table covering every common password multiplied by every possible salt becomes computationally infeasible and requires an absurd amount of storage.
2. Protecting Against Identical Password Hashes: As shown with Alice and Bob, salting ensures that two users with the same password will have different hashes. This prevents an attacker who cracks one hash from automatically compromising all accounts sharing that same password.
3. Preventing Discovery of Password Reuse Across Users: Related to the point above, by looking at the database, an attacker cannot easily spot users who might have chosen the same weak password just by comparing hash values.
4. Minimal User Burden: The end-user experience remains unchanged. They just type their password. All the salting magic happens behind the scenes.

Doing It Right: The "Forbidden" Best Practices

Simply knowing about salting isn't enough; implementing it correctly is critical. Mistakes can render the technique useless.

1. Unique Salts for Every Password

This is non-negotiable. Using the same salt for all passwords, or reusing salts, completely defeats the primary purpose of salting. If the salt is constant, an attacker only needs to precompute hash(password || common_salt). This is effectively like having no salt at all for rainbow table attacks, and identical passwords will still yield identical salted hashes.

Common Mistake: Salt Re-use Using the same salt value for multiple passwords, or worse, for all passwords in a system. This significantly weakens the defense against precomputed tables and allows attackers to identify and potentially crack groups of users who share the same password.

2. Generating Truly Random and Sufficiently Long Salts

The randomness and length of the salt are crucial for making precomputation infeasible.

• Randomness: Salts should be generated using a Cryptographically Secure PseudoRandom Number Generator (CSPRNG).

  Definition: Cryptographically Secure PseudoRandom Number Generator (CSPRNG) A CSPRNG is an algorithm for generating a sequence of numbers that approximates the properties of random numbers, but with the additional requirement that the sequence is computationally unpredictable. It is practically impossible for an attacker to distinguish the output of a CSPRNG from truly random data, or to predict future outputs based on past outputs.

  Using predictable sources like timestamps or simple incrementing counters is a severe mistake. An attacker could easily guess or reproduce these "salts" and build limited precomputation tables. While the article mentions combining random values with timestamps or user data, the random value component is the critical part providing unpredictability.

• Length: The salt needs to be long enough to provide a vast number of possible unique values. Short salts (like the 12-bit salts used in early Unix) were acceptable for their time but are no longer sufficient. A salt of 16 bytes (128 bits) or more is generally considered good practice today. This length ensures that the space of password || salt combinations is enormous, making it computationally prohibitive to precompute hashes for even common passwords across all possible salt values.

Common Mistake: Insufficient Salt Length Using salts that are too short. While unique, a short salt might still allow an attacker to precompute hashes for every likely password combined with every possible short salt value, creating a smaller, but still usable, precomputation table. Aim for at least 16 bytes (128 bits).

3. Combining Salt and Password Correctly

While simple concatenation (password || salt) is common and effective with strong hash functions, the key is that the salt is added before hashing. Some systems might use more complex combinations, but simple concatenation is standard and well-understood.

4. Storing Salt and Hash Securely (But Knowing the Salt is Okay)

The salt and the resulting hash must be stored together in the database. The salt itself does not need to be encrypted because knowing the salt does not allow an attacker to reverse the hash. The salt's purpose is not secrecy, but uniqueness and randomization of the input to the hash function. However, the database containing the salts and hashes should, of course, be protected against unauthorized access.

Real-World Implementations: Where the Forbidden Code Lives

Salting isn't just a theoretical concept; it's a fundamental building block of secure systems.

Unix/Linux Password Security

Historically, Unix systems stored password hashes in the /etc/passwd file, which was world-readable. Early implementations used a two-character salt (4,096 possible values) prepended to the password before hashing with a variant of DES. The salt and hash were stored together in /etc/passwd. While this was a breakthrough at the time, the limited salt length and the public nature of the file eventually became vulnerabilities.

The move to the shadow password system addressed the public readability issue by storing the password hashes and salts in a separate file (typically /etc/shadow) that is only readable by the root user. Modern systems also use longer salts (e.g., 8 characters in older shadow systems, much longer with modern hash algorithms) and stronger hashing algorithms (like bcrypt, scrypt, or Argon2, which incorporate salting and key stretching).

While the shadow file provides essential access control, salting remains crucial. In environments with centralized password management pushing credentials to multiple machines, the security of the hashing (including proper salting) is still paramount, as an attacker compromising one machine's root account might gain access to the shadow file.

Web Applications

Storing password hashes in a web application's database is standard practice. However, these databases are frequent targets of attacks, including SQL injection. If a database is compromised and passwords were not properly salted, an attacker immediately gains access to easily crackable hashes using precomputed tables.

Using a unique, random salt for each user's password hash in the database is a fundamental security requirement for web applications. It vastly increases the effort required for an attacker to crack multiple passwords even if they steal the entire user database. Given the common user behavior of reusing passwords across different websites, proper salting on your site protects your users even if their password is leaked elsewhere.

Related Concepts: More Tools in the Belt

Salting isn't the only technique involving adding random data to cryptographic processes. It's conceptually related to:

• Cryptographic Nonces: A "number used once," often random or pseudorandom, used in cryptographic communication to prevent replay attacks. Like salts, they introduce randomness, but their context is typically protocol execution rather than data storage.
• Initialization Vectors (IVs): In symmetric-key encryption, an IV is a fixed-size random or pseudorandom block that is XORed with the first block of ciphertext (or plaintext, depending on the mode) to ensure that identical plaintext blocks encrypt to different ciphertext blocks. Like salts, they are non-secret but must be unique (or at least unpredictable) per encryption operation with the same key.
• Padding: Adding extra data to the end of a message to make its length a multiple of the block size required by certain cryptographic algorithms. While not random and primarily related to block alignment, it also adds variability to the input.
• Peppers: A term sometimes used for a secret value added to a password in addition to a salt before hashing. Unlike a salt, a pepper is not stored with the hash and must be kept secret by the system. Compromise of the database alone would not reveal the pepper, adding another layer of defense. However, managing the secrecy of a pepper introduces operational complexity.

Conclusion: Embrace the Salt

Salting is not a silver bullet, but it is an absolutely essential component of any robust password storage system. It directly counters powerful, widely used attack techniques like rainbow tables and protects against vulnerabilities arising from users choosing common or identical passwords.

In the "underground" world of building secure systems that actually work against real adversaries, understanding why salting is necessary and how to implement it correctly (unique, random, long salts generated by a CSPRNG) is non-negotiable. Don't settle for just hashing; add the salt, guard your gates, and keep those secrets secure. This is foundational knowledge they should teach, but often don't emphasize enough. Now you know.