Hashing and Salting

Hashing and Salting: A Complete CDPSE Guide for Privacy Engineering

Introduction
Hashing and salting are core techniques in privacy engineering. They let organizations protect personal data, verify integrity and store credentials without keeping the original values. For the ISACA CDPSE (Certified Data Privacy Solutions Engineer) exam, you need to understand what hashing and salting are, why they matter for privacy by design, how they work technically, where their limits lie, and how to pick the right answer in scenario questions.

Why Hashing and Salting Are Important
Privacy engineering aims to reduce the risk that personal information is exposed, misused or re-identified. Hashing and salting support this goal in several ways.

1. Data minimization and privacy by design: Hashing lets a system confirm that two values match without storing the original value. Password verification is the classic example. This supports the principle of collecting and keeping only what is necessary.

2. Breach impact reduction: If a database of properly salted and hashed passwords is stolen, attackers cannot simply read the passwords. They must try to crack each one individually, which is expensive and slow.

3. Integrity assurance: Hashes detect whether data, files, logs or messages have been altered. This supports accountability and the integrity principle found in frameworks such as GDPR Article 5(1)(f).

4. Pseudonymization: Hashing identifiers, especially with a secret key or salt, can replace direct identifiers with tokens. This allows analytics, data matching or research while reducing direct identifiability.

5. Regulatory alignment: Regulations and standards encourage appropriate technical measures to protect personal data. Examples include GDPR, CCPA/CPRA, HIPAA, PCI DSS and NIST SP 800-63B. Properly implemented hashing and salting are recognized safeguards.

What Is Hashing?
A hash function is a mathematical algorithm that takes an input of any size and produces a fixed-length output. That output is called a hash value, digest or fingerprint.

Key properties of a cryptographic hash function:
- Deterministic: The same input always produces the same output.
- Fixed-length output: SHA-256 always produces 256 bits, no matter the input size.
- Pre-image resistance (one-way): Given a hash, it is computationally infeasible to find the original input.
- Second pre-image resistance: Given an input, it is infeasible to find a different input with the same hash.
- Collision resistance: It is infeasible to find any two different inputs that produce the same hash.
- Avalanche effect: A tiny change in the input, even one bit, produces a dramatically different hash.

Important distinction: Hashing is not encryption. Encryption is reversible with a key; it is a two-way function designed for confidentiality with later recovery. Hashing is a one-way function. If the business needs to retrieve the original value later, hashing is the wrong control and encryption should be used.

Common hash algorithms:
- MD5: Broken; collisions are easy to produce. Do not use for security.
- SHA-1: Deprecated because practical collision attacks exist.
- SHA-2 family (SHA-256, SHA-384, SHA-512): Currently strong general-purpose hashes.
- SHA-3: Newer standard with a different internal design (Keccak).
- Password-specific algorithms: bcrypt, scrypt, Argon2 (winner of the Password Hashing Competition) and PBKDF2. These are deliberately slow and/or memory-hard.

What Is Salting?
A salt is a random value, unique per record, that is combined with the input before hashing. The salt is usually stored alongside the hash in plaintext. It does not need to be secret; its job is to be unique and unpredictable.

Without salt, two users with the password "Summer2024" would have identical hashes. Attackers could then use precomputed tables (rainbow tables) or dictionary lookups to reverse common hashes instantly. Salting:
- Ensures identical inputs produce different hashes.
- Defeats rainbow tables and precomputed dictionary attacks.
- Forces attackers to attack each hash individually.
- Hides the fact that multiple users share the same password.

Related concepts:
- Pepper: A secret value added to all inputs before hashing and stored separately from the database, for example in a hardware security module (HSM) or secrets vault. Unlike a salt, a pepper must be kept secret. If the database is stolen but the pepper is not, cracking becomes much harder.
- Key stretching (work factor/iterations): The hash is applied many times, or a slow algorithm is used, so that each guess costs the attacker significant time. bcrypt's cost factor, PBKDF2's iteration count and Argon2's time and memory parameters implement this.
- HMAC (keyed hash): A hash combined with a secret key, such as HMAC-SHA256. It provides integrity and authenticity. It is also a stronger pseudonymization method than a plain hash, because without the key an attacker cannot rebuild the mapping.

How Hashing and Salting Work: Step by Step
Password storage (registration):
1. The user creates a password.
2. The system generates a cryptographically secure random salt, for example 16 bytes or more, using a CSPRNG.
3. The system combines the salt (and optionally a pepper) with the password.
4. The combination is processed by a slow, adaptive algorithm such as Argon2id, bcrypt, scrypt or PBKDF2 with a high iteration count.
5. The salt, algorithm parameters and resulting hash are stored. The plaintext password is never stored.

Password verification (login):
1. The user enters a password.
2. The system retrieves the stored salt and parameters for that user.
3. It recomputes the hash with the entered password.
4. It compares the result with the stored hash, ideally using a constant-time comparison.
5. If they match, the user is authenticated.

Pseudonymization of identifiers:
An email address or national ID can be hashed so that datasets can be joined without exposing the raw identifier. However, a plain unsalted hash of a low-entropy identifier is easily reversed by brute force. Phone numbers, national ID numbers and email addresses all have predictable formats. Best practice is to use a keyed hash (HMAC) or a secret salt/pepper managed under strict key management. Remember that under GDPR, hashed data is generally pseudonymized, not anonymized, and therefore remains personal data.

Integrity verification:
A hash of a file, log or dataset is computed and stored securely. Later, the hash is recomputed and compared. A mismatch indicates tampering or corruption. Digital signatures combine hashing with asymmetric encryption to provide integrity, authenticity and non-repudiation.

Limitations and Risks to Know
- Low-entropy inputs: Hashing short or predictable values, such as dates of birth, ZIP codes, phone numbers or SSNs, offers weak protection. The input space is small enough to enumerate.
- Fast hashes for passwords: SHA-256 alone is too fast for password storage. GPUs can compute billions of hashes per second.
- Reused or static salts: A single salt for all users largely defeats the purpose. Salts must be unique per record.
- Broken algorithms: MD5 and SHA-1 should be retired.
- Linkability: Deterministic hashes of the same identifier across datasets allow records to be linked. This can create re-identification and profiling risks.
- Not anonymization: Hashed personal data typically remains personal data under privacy law.
- Key/pepper management: If a pepper or HMAC key is compromised, the protection collapses. Keys must be rotated and protected, for example in an HSM.

Hashing in the CDPSE Context
CDPSE domains cover Privacy Governance, Privacy Architecture and Data Lifecycle. Hashing and salting appear mostly in Privacy Architecture, which covers technical privacy controls, privacy-enhancing technologies, cryptography and identity management. They also appear in Data Lifecycle, which covers data minimization, retention, de-identification and secure storage. Expect questions that ask you to:
- Pick the best control to protect stored credentials.
- Distinguish hashing from encryption, tokenization, masking and anonymization.
- Identify the weakness in a described implementation, such as unsalted MD5.
- Decide whether hashed data is still personal data.
- Choose an appropriate technique for pseudonymizing identifiers for analytics.

Comparison With Related Techniques
- Encryption: Reversible with a key; use when the original data must be recovered.
- Hashing: One-way; use when you only need to verify or compare.
- Tokenization: Replaces data with a random token. The mapping is stored in a secure vault, and the original can be retrieved through the vault. It is common in payment card environments.
- Masking: Hides part of the data for display, such as XXXX-XXXX-XXXX-1234.
- Anonymization: Irreversibly removes the ability to identify individuals, considering all reasonably likely means. Hashing alone rarely achieves this.

Exam Tips: Answering Questions on Hashing and Salting
Tip 1: Match the control to the business need. If the scenario requires retrieving the original data, choose encryption, not hashing. If it only needs verification, as with passwords, choose salted hashing with a slow algorithm.

Tip 2: For passwords, the best answer is salted, slow, adaptive hashing. Look for Argon2, bcrypt, scrypt or PBKDF2 with a unique salt per user. Answers proposing encryption of passwords, plain SHA-256 or MD5 are usually wrong or less preferred.

Tip 3: Remember the purpose of salt. Salt defeats rainbow tables and precomputed attacks, and it makes identical passwords produce different hashes. Salt does not need to be secret. If an option says the salt must be kept secret, that describes a pepper or key.

Tip 4: Unique per record. If a scenario describes a single, system-wide salt, recognize it as a weakness.

Tip 5: Hashed personal data is usually pseudonymized, not anonymized. When asked whether hashed emails or IDs fall outside privacy law, the answer is typically no. They remain personal data if re-identification is reasonably possible, especially for low-entropy data.

Tip 6: Watch for low-entropy traps. Hashing SSNs, phone numbers or birth dates without a secret key is weak because of brute-force enumeration. The better answer is usually a keyed hash (HMAC), tokenization or a secret pepper with proper key management.

Tip 7: Know deprecated algorithms. MD5 and SHA-1 are not acceptable for security purposes. If asked to recommend an improvement, migrate to SHA-256 or above for integrity. For passwords, migrate to Argon2, bcrypt, scrypt or PBKDF2.

Tip 8: Integrity questions point to hashing; authenticity points to HMAC or digital signatures. A plain hash detects change. HMAC adds a shared secret to prove origin. Digital signatures add non-repudiation.

Tip 9: Think like a privacy engineer, not just a security engineer. CDPSE answers often favor the option that minimizes data, reduces identifiability and is embedded by design early in the SDLC. Ask yourself which option reduces privacy risk to the data subject most effectively while meeting the business requirement.

Tip 10: Look for keywords.
- Rainbow table leads to salt.
- Brute force/GPU cracking leads to key stretching or slow hashing.
- Database stolen but secret held elsewhere leads to pepper or HSM.
- Need to recover leads to encryption or tokenization.
- Detect tampering leads to hashing or HMAC.
- Join datasets without exposing identifiers leads to keyed hashing or tokenization.

Tip 11: Eliminate absolute statements. Options claiming hashing makes data "completely anonymous" or "impossible to reverse in all cases" are usually incorrect, because weak inputs can be brute-forced.

Tip 12: Consider the lifecycle and governance angle. Good answers may mention documented cryptographic standards, algorithm agility (being able to upgrade algorithms), key management, periodic review of work factors, and rehashing passwords at next login when upgrading algorithms.

Sample Exam-Style Question
An organization stores user passwords using SHA-256 without salt. A privacy engineer is asked to recommend the MOST effective improvement. Which should be chosen?
A. Encrypt the SHA-256 hashes with AES
B. Switch to MD5 for faster performance
C. Use a unique random salt per user with an adaptive algorithm such as bcrypt or Argon2
D. Store passwords in plaintext in a restricted database

Answer: C. It addresses rainbow tables through the unique salt and brute-force speed through the adaptive work factor. Option A adds complexity without fixing the core weakness. Option B weakens security. Option D violates fundamental privacy and security principles.

Key Takeaways
- Hashing is a one-way, deterministic transformation used for verification and integrity. It is not encryption.
- Salting adds unique randomness per record to defeat precomputed attacks and hide duplicate values.
- For passwords, use slow, adaptive algorithms (Argon2id, bcrypt, scrypt, PBKDF2) with unique salts. Optionally add a pepper stored separately.
- Hashed personal data is generally pseudonymized and remains in scope of privacy regulations.
- Low-entropy identifiers need keyed hashing or tokenization, plus strong key management.
- In exam questions, align the technique with the requirement, recognize weak implementations, and favor privacy-by-design answers that minimize risk to individuals.