SY0-701 Question 42
Single answerHashing: SaltingA company discovers that an attacker copied its customer authentication database. During the incident review, the security team learns that several users who chose the same password have identical stored hash values. The team must redesign password storage so that future database thefts do not allow attackers to quickly identify users with matching passwords or efficiently use precomputed rainbow tables. Which change would BEST address this requirement?
- A
Generate a unique random salt for each password before hashing and store the salt alongside the resulting hash
- B
Encrypt each password with the company’s private key before hashing so identical passwords produce different outputs
- C
Store only a single system-wide salt value in a configuration file and append it to all passwords before hashing
- D
Hash each password twice with SHA-256 without using a salt to make the hashes harder to reverse
Show answer and explanation
Correct answer: A
Explanation
The best answer is to generate a unique random salt for each password before hashing and store that salt with the hash. Salting is specifically used to prevent identical passwords from producing identical stored hashes and to make precomputed attacks such as rainbow tables impractical. This directly addresses the scenario, where identical hashes revealed password reuse across accounts. Modern best practice is not merely to hash with a general-purpose algorithm like SHA-256, but to use a password-hashing function designed for credential protection, such as Argon2, bcrypt, scrypt, or PBKDF2, all of which support salting and configurable computational cost. This guidance aligns with widely accepted best practices such as NIST SP 800-63B, which recommends storing passwords in a form that is resistant to offline attacks using salted, iterated password hashing.
- A. Correct.
Correct. A unique random salt per password is the standard approach for password storage. Salting ensures that two users with the same password will have different stored hash values, and it significantly reduces the usefulness of rainbow tables and other precomputed attacks. The salt is not secret and is typically stored with the hash. In practice, organizations should use a password-hashing function designed for credential storage, such as bcrypt, scrypt, Argon2, or PBKDF2, which incorporate salting and work factors.
- B. Incorrect.
Incorrect. Encrypting with a private key is not how password storage should be handled, and this option mixes asymmetric cryptography concepts with password hashing in an unsafe and impractical way. If the same process and key are applied to identical passwords, the result is still deterministic unless a proper random value is introduced. Also, private keys are not intended to be used this way for password storage.
- C. Incorrect.
Incorrect. A single system-wide salt is better than no salt in some limited contexts, but it does not solve the main problem in this scenario: users with the same password would still end up with identical hashes because the same salt is applied to every password. It also provides much less protection against large-scale cracking than a unique salt per password.
- D. Incorrect.
Incorrect. Hashing twice without a salt remains deterministic, so identical passwords still produce identical outputs. Double-hashing does not meaningfully address rainbow table resistance the way unique salts do. It also does not replace the need for a password-specific random salt or a dedicated password-hashing algorithm with configurable cost.