SY0-701 Question 45
Single answerKey stretchingA SaaS company discovers that a copy of its authentication database was exposed through a misconfigured backup repository. The security team confirms that passwords were not stored in plaintext, but management is concerned that attackers could still use GPUs to perform offline cracking against the stolen password hashes. The development team needs to reduce the likelihood of successful brute-force and dictionary attacks without requiring users to choose longer passwords immediately. Which action would BEST address this risk?
- A
Increase the computational cost of password hashing by using a key-stretching password hashing function such as PBKDF2, bcrypt, or scrypt with unique salts
- B
Encrypt the password database with TLS 1.3 so attackers cannot read the hashes after exfiltrating the file
- C
Store password hashes with SHA-256 only, because modern hash algorithms are secure and fast
- D
Replace password hashing with reversible encryption so the application can recover lost passwords for users
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use key stretching through a dedicated password hashing algorithm such as PBKDF2, bcrypt, or scrypt, combined with unique salts. In an offline attack scenario, the attacker can repeatedly test password guesses against stolen hashes without interacting with the live application, so rate limiting and network protections do not help. Key stretching raises the cost per guess, making GPU-accelerated cracking less efficient and buying defenders time. This aligns with established industry guidance, including NIST SP 800-63B, which recommends salted, iterated password hashing and specifically references PBKDF2 as well as memory-hard password hashing schemes where appropriate. Security best practices also emphasize that general-purpose fast hashes like SHA-256 alone are not sufficient for password storage, and that passwords should not be stored with reversible encryption.
- A. Correct.
Correct. Key stretching intentionally makes password hashing slower and more resource-intensive, which significantly increases the cost of offline brute-force and dictionary attacks after a database compromise. Using password-specific hashing functions such as PBKDF2, bcrypt, or scrypt, along with a unique salt per password, is a widely accepted best practice. The goal is to force an attacker to spend far more time and compute power on each guess while keeping legitimate logins acceptably fast.
- B. Incorrect.
Incorrect. TLS 1.3 protects data in transit between systems, not data at rest in a stolen database file. If an attacker already exfiltrated the backup repository, TLS does nothing to prevent offline cracking of the hashes. Someone might choose this option because TLS is strongly associated with confidentiality, but it is not a control for hardening stored password hashes against cracking.
- C. Incorrect.
Incorrect. SHA-256 is a cryptographic hash function, but by itself it is designed to be fast, which makes it a poor choice for password storage. Fast hashing helps attackers test more guesses per second during offline attacks. This is a common misconception: a strong general-purpose hash algorithm is not automatically a strong password hashing solution unless it is used within a purpose-built, slow, salted password hashing scheme.
- D. Incorrect.
Incorrect. Reversible encryption is not appropriate for password storage because it creates the possibility of recovering the original password if the encryption keys are compromised. Password verification should generally rely on one-way hashing, not decrypting stored secrets. A user password reset process is the proper way to handle forgotten passwords, not storing passwords in a recoverable form.