📖 Story📚 Glossary🗺️ Concepts💡 Examples🃏 Flashcards✅ Quiz🎯 Tricks
Chapter 16 · Quiz

Hashing & Digital Signatures Quiz

Select your answer, then click Reveal Answer to check immediately — or grade all at once at the bottom.

Question 1: A security team discovers that a company stores passwords as unsalted MD5 hashes. An attacker who steals the database could most efficiently crack passwords using which attack?

Correct answer: B. Unsalted MD5 hashes are ideal for rainbow table attacks — precomputed tables of MD5 hashes for common passwords allow instant lookup. Salting would have defeated this by making every user's hash unique even with the same password. MD5's collision vulnerabilities also make the problem worse — but the primary attack vector for unsalted hashes is the precomputed rainbow table.

Question 2: An administrator wants to verify that a software package downloaded from a vendor website has not been tampered with. What should they compare?

Correct answer: B. File hash comparison is the standard integrity verification method. The vendor publishes the expected hash alongside the download. After downloading, compute the hash locally and compare — any modification (even 1 byte) produces a completely different hash. File size (A) can be spoofed and has no cryptographic guarantee. Timestamps (C) are easily modified.

Question 3: Which operation does the sender perform to create a digital signature on a document?

Correct answer: C. Digital signing: (1) hash the document to create a digest, (2) encrypt the digest with YOUR OWN private key — this is the signature. Encrypting the full document (B) is too slow and doesn't produce a usable signature. Encrypting with the recipient's public key (A, D) is encryption for confidentiality — not signing. The private key in signing proves identity; only you hold that key.

Question 4: A CFO digitally signs a purchase authorization email. Three days later, she denies ever sending it. What property of digital signatures defeats her claim?

Correct answer: C. Non-repudiation is the inability to deny an action. A digital signature is created using the signer's private key — which is theirs alone. The signed email is mathematical proof that the holder of the CFO's private key created it. She cannot claim someone else signed it without also claiming her private key was stolen (which would be a different security incident to investigate).

Question 5: Why is salting necessary when hashing passwords for storage?

Correct answer: C. Salts are random unique values added per-user before hashing. Even if two users have the same password, their salts differ, so their hashes differ. An attacker with the hash and salt cannot use precomputed rainbow tables — they must brute-force each account individually using that user's specific salt. The salt is NOT secret (D is wrong) — it is stored alongside the hash. Its purpose is uniqueness, not secrecy.

Matching: Hash & Signature Concepts

Match each term to its definition.

TERM

Collision
Salt
Non-repudiation
HMAC

DEFINITION

Two different inputs that produce the same hash output — breaks security of algorithms like MD5
Random unique value added to each password before hashing — defeats rainbow tables
The inability to deny having performed an action — guaranteed by digital signatures using a private key
Hash-based Message Authentication Code — combines hashing with a shared secret key for integrity and authenticity

Performance Task

A hospital is auditing its authentication and software integrity controls. Current state: (1) passwords stored as unsalted SHA-1 hashes, (2) no verification of software packages before deployment to 500 servers, (3) no protection against insider modification of critical configuration files. Design improvements for all three issues.

Model Answer:

1. Password storage improvement:
Migrate from unsalted SHA-1 to bcrypt or Argon2 (with automatic unique salt per user). Process: at each user's next login, hash the entered password with bcrypt and store the bcrypt hash (replacing the old SHA-1 hash). Force all users to log in within 30 days — at that point, all hashes are migrated. bcrypt provides: automatic salting (unique per user), slow hashing (~200ms per attempt vs. millions/second for SHA-1), and tunable cost factor for future-proofing.

2. Software package verification:
Implement hash verification for all software deployments. Process: obtain SHA-256 hashes from vendor package manifests or HTTPS download pages. Before deployment to any server, compute SHA-256 of the downloaded package and compare to the vendor-published hash. If mismatch → do not deploy → investigate. Automate this check in the deployment pipeline so it cannot be skipped. For vendor packages with code signing certificates, verify the digital signature as well — this additionally confirms the publisher identity.

3. Configuration file integrity monitoring:
Deploy a File Integrity Monitor (FIM) on all 500 servers. Initial setup: hash all critical configuration files (web server configs, database configs, OS system files, authentication configs) to create a baseline. FIM checks all monitored files on a schedule (every 15 minutes recommended). Any hash change triggers an immediate alert to the security team with: which file changed, when, and what changed. Review alerts promptly — configuration drift may indicate insider modification, malware, or unauthorized change management bypass. Store FIM baselines in a tamper-evident, append-only log system.