This distinction trips up students because both hashing and encryption transform data beyond recognition. The critical difference is reversibility, and the exam tests this repeatedly in password storage scenarios.
The password storage logic — why it does not need reversal:
Registration: User enters "MyPassword123" → SHA-256 → stored hash (64 hex chars)
(original NEVER stored)
Login: User enters "MyPassword123"
↓
System hashes entered password → SHA-256 → new hash
↓
Compare new hash to stored hash — MATCH → access granted
No decryption. No reversal. Just hash-and-compare.
Why encryption is WRONG for password storage:
- Encryption requires a key. If the key is stolen alongside the database — both are often on the same server — all passwords are exposed. The encryption added complexity without security benefit.
- There is no reason to decrypt a password. The system only needs to verify "is this the correct password?" — it never needs to display or transmit the actual password back to anyone.
- If an admin claims they need to look up user passwords, that is a design flaw (and a red flag), not a reason to use encryption.
The exam answer pattern:
- "Store passwords so they cannot be recovered even if the database is stolen" → hashing
- "Which technique transforms data and cannot be reversed?" → hashing
- "Which technique produces a fixed-length output regardless of input size?" → hashing
- "An administrator forgot their password — the help desk must reset it, not recover it — why?" → passwords are hashed; there is no copy of the original to recover
MD5 and SHA-1 are deprecated — know why:
The exam explicitly notes MD5 and SHA-1 as deprecated due to collision vulnerabilities. A collision means two different inputs produce the same hash. For password storage: if an attacker can find any input that produces the same hash as a stored password — not necessarily the actual password — they can authenticate as that user. SHA-256 and SHA-3 are current standards. For the exam: SHA-256 = good; MD5 = deprecated; SHA-1 = deprecated.
Tokenization is the most commonly confused technique on the exam because students know encryption and hashing but have less experience with tokenization as a distinct concept. The exam specifically tests the "no mathematical relationship" property.
The three-way distinction:
Reverse: apply key → 4111-1111-1111-1111 (math undoes it)
Hashing: 4111-1111-1111-1111 → SHA-256 → a1b2c3d4e5... (fixed-length digest)
Reverse: IMPOSSIBLE — hash cannot be reversed
Tokenization: 4111-1111-1111-1111 → token service → 8937-2841-7734-0092 (token)
Reverse: query token service → 4111-1111-1111-1111
Math reverse: IMPOSSIBLE — the token is an arbitrary assignment, not computed
The "no mathematical relationship" property — why it matters:
With encryption: an attacker who steals the ciphertext and finds the key can decrypt. There is a mathematical path from ciphertext to plaintext via the key. With tokenization: even if the attacker steals the token AND knows every tokenization algorithm ever invented, they cannot compute the original card number from the token. There is nothing to compute. The only path from token to original is through the token service — which the attacker does not have access to.
The exam scenario patterns:
- "The company wants to store credit card data so that even if the database is stolen, the card numbers cannot be recovered mathematically" → tokenization (note: not encryption — encryption has a mathematical reversal path via the key)
- "Apple Pay / Google Pay / mobile payments" → tokenization (this is the primary real-world example in the exam objectives)
- "No encryption overhead" → tokenization (systems just pass tokens around; no crypto operations on the merchant side)
- "One-time use token" → tokenization (tokens used for a single transaction; cannot be replayed)
- "Replace sensitive data with a non-sensitive substitute that has no mathematical relationship to the original" → tokenization (exact exam phrasing)
The "no encryption overhead" practical benefit:
Every encryption operation requires CPU time for the mathematical transformation. In a high-volume transaction processing system — millions of card transactions per day — encryption overhead adds up. Tokenization avoids this: passing around tokens is just a string lookup, not a cryptographic operation. The crypto happens once (when the token is created) and once per authorization (when the token service resolves it) — not on every merchant system transaction.
Students frequently conflate masking and tokenization because both "hide" the real value from users. The exam question will distinguish them by whether the original data is still stored in the primary system.
The key diagnostic question:
Does the original sensitive value still exist in the main database/system, or has it been removed entirely?
Masking:
Database: 4111-1111-1111-1532 <-- STILL HERE
Call center UI shows: **** **** **** 1532
Payment system retrieves: 4111-1111-1111-1532 (full number, when needed)
If database breached: attacker finds 4111-1111-1111-1532
Tokenization:
Database: 8937-2841-7734-0092 <-- TOKEN ONLY, no real number here
Call center UI shows: 8937-2841-7734-0092 (the token itself, or its masked form)
Payment system sends: 8937-2841-7734-0092 to payment network → token service maps → charges card
If database breached: attacker finds 8937-2841-7734-0092 → mathematically useless
What the exam specifically tests:
- "Which technique removes the sensitive value from the merchant's systems entirely?" → tokenization
- "Which technique can reduce PCI DSS scope by eliminating card data from merchant systems?" → tokenization (masking does not — the card number is still in the database)
- "A call center agent sees only the last four digits of a card number. The full number is stored in the database for payment processing. Which technique?" → masking
- "Which technique hides sensitive data for display purposes without eliminating the original from storage?" → masking
Where masking is the right tool vs. tokenization:
- Masking is right when: the system needs the full value for certain authorized operations (the payment processor must charge the card), but you want to restrict who can see the full value in the UI
- Tokenization is right when: you want to eliminate the real sensitive value from a system entirely — it is never needed there; only the token is used
These two techniques are tested separately but both have distinctive exam patterns. Segmentation answers "how do we reduce how much is exposed in a breach?" Obfuscation answers "why does this code do the same thing but look completely different?"
Segmentation — the blast radius concept:
The exam will present a scenario where a single database stores everything — and ask how to reduce the impact of a future breach. The answer is always some form of segmentation (data distribution, separate databases, tiered security).
Single database breach:
Attacker compromises 1 endpoint → gets PII + payment data + order history + everything
One key = full access to all data
Segmented architecture breach:
Attacker compromises 1 endpoint → gets ONLY the data in that segment
Must separately compromise each isolated database with its own credentials/controls
Segmentation exam patterns:
- "An organization wants to reduce the amount of data exposed in any single database compromise" → data segmentation
- "The most sensitive data should receive the highest level of security investment" → data segmentation (tiered security by sensitivity)
- "After a breach, investigators found all customer data in one place" → lack of segmentation was a contributing factor
Obfuscation — the "same function, unreadable code" signature:
Every obfuscation exam question will include the detail that the code or data still works the same way. If functionality changed, it is not obfuscation — it is broken code. The preserved functionality is what makes malware obfuscation effective: the malware still does what it is designed to do; only the code's appearance is changed to evade detection.
Obfuscation exam patterns:
- "Security researchers analyze a malware sample and find the code is extremely difficult to read — variables have random names, the logic is convoluted — but when executed, it performs the same malicious actions as known malware" → obfuscation (malware evading signature detection)
- "A software company transforms its code before distribution so that the algorithm cannot be easily copied by competitors — the software still runs correctly" → obfuscation (legitimate IP protection)
- "Which technique makes code hard to understand while preserving its functionality?" → obfuscation
- "Obfuscation is NOT encryption" — the exam may explicitly test this: obfuscation has no key, can be reversed by analysis, does not provide cryptographic security
The obfuscation vs. encryption distinction the exam loves:
- Encryption: requires a key to reverse; provides cryptographic security; two-way but mathematically secured
- Obfuscation: no key; reversible with analysis and effort; does not provide cryptographic security; is security-through-obscurity only
- Exam question: "Which technique protects code by making it hard to read without providing cryptographic security?" → obfuscation (not encryption)
Scenario A: A security engineer is reviewing the data protection strategy for an e-commerce platform. The platform: (1) stores customer passwords in an MD5 hash database; (2) displays full credit card numbers to call center agents; (3) transmits credit card numbers to the payment processor using encryption; (4) backs up all customer data — PII, payment data, order history — to a single cloud backup database. Identify the specific protection technique problem in each of the four areas and state the correct control for each.
Show Answer
1. Passwords stored as MD5 hashes — Problem: deprecated hash algorithm with known collision vulnerabilities.
MD5 is broken for cryptographic purposes. Collision attacks allow an attacker to find a different input that produces the same MD5 hash as a stored password — potentially enabling authentication bypass without knowing the actual password. Additionally, MD5 is fast (designed for speed, not security), making brute-force cracking of common passwords computationally cheap. Fix: migrate to SHA-256 at minimum. Better: use bcrypt or Argon2 (purpose-built password hashing with work factors and salting). The change requires re-hashing all passwords — users must log in once post-migration so the new hash can be computed and stored.
2. Full credit card numbers displayed to call center agents — Problem: unnecessary exposure of sensitive data to agents who do not need the full number.
Call center agents need to identify which card a customer is asking about — they do not need the full card number to answer "is this the Visa card you used last Tuesday?" Displaying the full number to every agent increases the surface area for insider theft (an agent could manually record card numbers) and increases PCI DSS compliance burden (all agent workstations become in-scope). Fix: implement data masking — display only the last four digits (**** **** **** 4532). The payment processing system can still retrieve the full number from the database when needed; agents see only the identification fragment.
3. Credit card numbers transmitted to payment processor using encryption — No problem here.
Encrypting card data in transit is the correct control for data in transit. This is appropriate — card numbers must be encrypted when transmitted over any network. The question is whether this is sufficient: it protects the transmission but does not address storage (are numbers stored encrypted at rest?) or the display issue in area 2. Encryption in transit is correct; it is just one layer of a complete data protection strategy.
4. All customer data in a single cloud backup database — Problem: no data segmentation; a single backup database breach exposes everything.
A monolithic backup database containing PII, payment data, and order history in one place means a single compromise of the backup system yields everything. This also creates maximum PCI DSS and privacy regulation scope (all data in one place = largest possible regulated dataset). Fix: implement data segmentation in the backup strategy — separate backup sets for PII (highest security, most restricted access), payment data (PCI DSS in-scope, HSM-protected encryption), and order history (lower sensitivity, standard backup controls). Each segment should have access controls proportional to its sensitivity, and the backup system should not be a single database that any one compromise can drain entirely.
Scenario B: A malware analyst receives a sample of suspicious code. When they view the source, the code uses single-character variable names (a, b, c...), has no comments, all string literals are replaced with hex escape sequences, and function names appear to be randomly generated. When the analyst runs the code in a sandbox, it performs exactly the same network scanning and data exfiltration as a known malware family. A colleague says: "Maybe the code was encrypted to hide what it does." Evaluate the colleague's statement and identify the correct technique.
Show Answer
The colleague's statement is incorrect — this is obfuscation, not encryption.
Why it is not encryption: Encrypted code cannot run. If the code were encrypted ciphertext, the CPU could not execute it — the instruction set would be meaningless noise. The fact that the code runs correctly in the sandbox and performs the expected malicious actions proves the code is executable. Encrypted data does not execute; obfuscated code does. Encryption requires a key to make the content readable; the content here is already in a form the CPU can execute.
Why it is obfuscation: All the characteristics described are classic code obfuscation techniques: (1) variable renaming — meaningless single-character names replace descriptive identifiers; (2) string encoding — hex escape sequences replace readable string literals so keyword-matching antivirus cannot find strings like "download payload" or "registry run key"; (3) random function names — prevents signature matching on function names that appear in known malware. The result: the code looks nothing like the known malware family it is derived from, so signature-based antivirus does not match it. But it runs identically — the behavior is the same, only the code's appearance is different.
The security implication: Obfuscation is the primary technique malware authors use to evade signature-based detection. Security tools like antivirus that match known patterns (signatures) of malicious code cannot match obfuscated variants because the patterns have changed. This is why behavioral detection (running the code in a sandbox and observing what it does) catches obfuscated malware that signature scanning misses — behavior is harder to disguise than code appearance. The malware cannot obfuscate the fact that it makes network connections, writes to startup registry keys, and exfiltrates data — those are observable actions regardless of how the code that performs them is written.
Scenario C: A healthcare system needs to share patient data with a research institution for a study on treatment outcomes. The research team needs the medical outcome data (diagnosis codes, treatment responses, medication effectiveness) but does not need to identify individual patients. The IT team proposes three options: (1) share the full patient records; (2) tokenize the patient identifiers and share the clinical data linked to tokens; (3) hash the patient identifiers and share the clinical data linked to hashes. Evaluate all three options and recommend the best approach.
Show Answer
Option 1 — Share full patient records: Inappropriate.
The research team does not need to identify individual patients — they need treatment outcome data. Sharing full records (name, address, SSN, DOB plus clinical data) exposes unnecessary PII to the research institution. This creates liability (HIPAA breach if the research institution is compromised), is more data than needed (violates the principle of minimal data sharing/data minimization under GDPR and HIPAA), and introduces the research institution as a second point of PII exposure.
Option 2 — Tokenize patient identifiers; share clinical data linked to tokens: Good approach.
Replace each patient's identifying information (name, SSN, MRN) with a token before sharing. The research institution receives clinical outcome data linked to token IDs (Patient-8937 had Diagnosis X, Treatment Y, Outcome Z). The researchers can track a patient's outcomes over time using the token as a pseudonymous identifier, but cannot determine who the patient is from the token alone. If the research data is leaked, no patient identities are exposed. The healthcare system retains the token-to-patient mapping in the token service — if the researchers find a significant result that requires identifying a specific patient for follow-up, the healthcare system can do so using the mapping. Best of both worlds: research utility preserved, patient identity protected.
Option 3 — Hash patient identifiers; share clinical data linked to hashes: Moderate approach, with a critical flaw.
Hashing patient identifiers (SHA-256 of SSN or name) and linking clinical data to those hashes preserves research utility (each patient has a consistent hash across their records, so longitudinal analysis works). And hashing is one-way — in principle, the research team cannot recover the original SSN from a SHA-256 hash. However, there is a well-known attack against hashed PII called a re-identification attack: if the adversary has a list of known patients (or can enumerate all possible SSNs, which is a finite space of 999,999,999 possibilities), they can hash each one and compare against the research database's hashes. SSNs are particularly vulnerable: they are drawn from a small, enumerable space. This attack is computationally feasible. The correct countermeasure — adding a secret salt to each hash — prevents this but makes the approach equivalent to tokenization in complexity. For this reason, tokenization (Option 2) is generally preferred over hashing for pseudonymization of structured identifiers like SSNs.
Recommendation: Option 2 (tokenization) is the best approach. It provides pseudonymization (research utility without patient identification), no mathematical path from token to patient identity, and the healthcare system retains the ability to re-identify if clinically necessary. Option 3 is workable with proper salting but has an enumeration attack vulnerability for structured identifiers that Option 2 avoids entirely.