SY0-701 Question 46
Single answerKey stretchingA security administrator is reviewing an internally developed web application's password storage design after a recent database exposure. The developers currently store passwords as a single SHA-256 hash with a unique salt for each user. Management is concerned that attackers could still crack weak passwords offline using GPUs. The administrator wants to recommend a change that specifically uses key stretching to make password guessing significantly more expensive without requiring users to change how they log in. Which solution BEST addresses this requirement?
- A
Replace the current scheme with PBKDF2 using a unique salt and a high iteration count for each password
- B
Encrypt the password database with AES-256 so attackers cannot perform offline cracking if the database is stolen
- C
Continue using SHA-256 with salts, but increase the password minimum length from 8 to 10 characters
- D
Store only an HMAC-SHA-256 of each password using a server-side key instead of a salted hash
Show answer and explanation
Correct answer: A
Explanation
Key stretching is used to make password cracking more resource-intensive by repeatedly processing the password with a salt through a deliberately expensive function. In practice, Security+ candidates should recognize PBKDF2, bcrypt, scrypt, and Argon2 as examples of password hashing or derivation approaches intended to resist offline attacks better than general-purpose fast hashes such as SHA-256. NIST guidance in SP 800-63B recommends storing memorized secrets using salted, iterated password hashing, and OWASP Password Storage Cheat Sheet similarly recommends modern password hashing algorithms with configurable work factors. In this scenario, the existing use of unique salts is good, but a single SHA-256 hash is too fast for password storage. PBKDF2 with a high iteration count is the best answer because it directly implements key stretching while preserving the same user login workflow.
- A. Correct.
Correct. PBKDF2 is a password-based key derivation function designed for key stretching. It combines a password with a salt and applies many iterations, deliberately increasing the computational cost of each password guess. This is exactly the goal when defending against offline cracking after a database breach. A unique salt prevents precomputed rainbow table attacks, and the high iteration count makes large-scale guessing more expensive for attackers using CPUs or GPUs.
- B. Incorrect.
Incorrect. Encrypting the password database can help protect data at rest, but it does not solve the core password storage problem. If attackers obtain both the database and the application server or encryption keys, they may still recover the stored values. Best practice is to store passwords using a dedicated password hashing or key stretching function, not rely on reversible encryption of password data.
- C. Incorrect.
Incorrect. Increasing password length requirements may improve password strength overall, but it does not implement key stretching. A single fast SHA-256 hash remains inexpensive for attackers to test at scale. This option addresses password policy, not the need to slow offline guessing with a computationally expensive derivation function.
- D. Incorrect.
Incorrect. HMAC-SHA-256 with a server-side key can add protection in some architectures, especially as a pepper-like control, but by itself it is not key stretching. HMAC is still a fast cryptographic operation unless paired with an intentionally slow password hashing approach. The question asks specifically for a change that uses key stretching to increase the cost of password guessing.