CISSP Software Development Security Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Use a key derivation function (e.g., bcrypt) with a per-user salt

  Why this is correct

  Using a key derivation function (KDF) like bcrypt with a per-user salt is the most secure method for storing passwords. Bcrypt is specifically designed to be computationally intensive and slow, making brute-force attacks economically infeasible by requiring significant processing power for each guess. The unique, randomly generated per-user salt ensures that even identical passwords produce different hashes, effectively neutralizing precomputed rainbow table attacks and dictionary attacks across multiple user accounts.

• ✗

  Encrypt passwords using AES-256 with a static key

  Why it's wrong here

  Encrypting passwords using AES-256 with a static key is fundamentally insecure for password storage because encryption is a reversible process. If the single static encryption key is ever compromised, all stored passwords can be immediately decrypted and exposed in plaintext. This method offers no protection against an attacker who gains access to both the encrypted data and the key, making it unsuitable for safeguarding sensitive user credentials.

• ✗

  Store passwords in plaintext but in a protected database

  Why it's wrong here

  Storing passwords in plaintext, even within a supposedly protected database, is an unacceptable security practice. While database protections like access controls and firewalls are important, they are not infallible. Any successful breach of the database's perimeter defenses, whether through SQL injection, insider threat, or zero-day exploit, would instantly expose all user passwords without any cryptographic barrier, leading to widespread account compromise and potential identity theft.

• ✗

  Hash passwords with SHA-256 without salt

  Why it's wrong here

  Hashing passwords with SHA-256 without a salt is highly vulnerable to various attacks, primarily rainbow tables and dictionary attacks. Without a unique salt, identical passwords will always produce the exact same hash value. Attackers can precompute a vast database of common password hashes (a rainbow table) and quickly match stolen hashes to their corresponding plaintext passwords, bypassing the need for individual brute-force attempts and compromising user accounts efficiently.

Go deeper

Related to this question