Security Fundamentals Practice Question 6: Password Storage Hashing
Security Fundamentals · Test 1 · question 6 of 10
A startup is building its own user login. The goal is to limit the damage if the user table is ever stolen. How should the application store user passwords?
Show answer and explanation
Answer:
To check a password, a system never needs the original back. It only needs to confirm that the user typed the same thing, so passwords should be hashed, not encrypted. When a database leaks, attackers run offline guessing, and the defences against that are:
- A slow, tunable hash (Argon2id, scrypt, bcrypt, PBKDF2) makes every guess expensive. OWASP names Argon2id first and bcrypt for legacy systems. - A unique random salt per password. OWASP explains that because the salt is unique for every user, an attacker has to crack hashes one at a time rather than hashing a guess once and comparing it against every stored hash.
Option C combines both.
- A is wrong because encryption is reversible. Anyone who obtains the key, or compromises the application that uses it, recovers every password in plain text. - B is wrong because OWASP states that fast hashes such as SHA-256 are not suitable for password storage, since they let attackers make huge numbers of guesses quickly. A single salt shared by every account also means one precomputed table cracks all of them. - D is wrong because SHA-512 is just as fast, and with no salt, identical passwords produce identical hashes and precomputed rainbow tables work.
Reference: OWASP Password Storage Cheat Sheet