Cyber Security Quiz: Password Storage
10 questions · exam conditions
0:00
Password StorageQuestion 1 of 10

A web application stores a password hash, a unique salt, and the hashing parameters for each user. The application does not retain the original passwords.

When a user later attempts to sign in, which process should the application use?

Decrypt the stored hash with the user's salt, and compare the recovered text with the submitted password.
Generate a new salt for the submitted password, and compare only the two salt values.
Hash the stored digest again with a new salt, and compare it with the submitted plaintext password.
Hash the submitted password with the stored salt and parameters, and compare the resulting digest securely.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Password Storage

Practice Password Storage in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Password Storage, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A web application stores a password hash, a unique salt, and the hashing parameters for each user. The application does not retain the original passwords.

When a user later attempts to sign in, which process should the application use?

  1. Decrypt the stored hash with the user's salt, and compare the recovered text with the submitted password.
  2. Generate a new salt for the submitted password, and compare only the two salt values.
  3. Hash the stored digest again with a new salt, and compare it with the submitted plaintext password.
  4. Hash the submitted password with the stored salt and parameters, and compare the resulting digest securely. (correct answer)
Explanation: When you see a question about password authentication, focus on one core principle: the original password is never stored, so verification must reconstruct the comparison — not reverse the hash. Here's how it works. Cryptographic hash functions are one-way: given a hash, you cannot recover the original input. When a user registers, the application hashes their password with a unique salt and stores the resulting digest. Later, at login, the only valid approach is to take the submitted password, apply the same stored salt and parameters, and re-run the hash. If the new digest matches the stored digest, the password is correct. That's exactly what D describes — and it's the right answer. A is dangerously wrong because it implies hashing is reversible (i.e., decryptable). It isn't. Confusing hashing with encryption is one of the most common misconceptions in security — hashing is a one-way transformation, not symmetric encryption. B fails for a different reason: comparing salt values tells you nothing about whether the password itself is correct. Salts are not secrets derived from the password; they're random values used to prevent precomputation attacks like rainbow tables. C is a trap for students who know salts are involved but misapply them. Re-hashing the stored digest with a new salt produces a meaningless output, and comparing it to plaintext is nonsensical. A quick study tip: remember that salts prevent precomputation attacks, not that they authenticate users directly. Authentication always works by re-deriving the hash from the submitted input and comparing digests — never by reversing or regenerating salts.

Question 2

An attacker steals a user table containing usernames, unique random salts, and salted password hashes. The salts were stored in the same table and are therefore visible to the attacker.

Which statement best describes the security value that the salts still provide?

  1. They reduce the usefulness of precomputed results and prevent one computation from being reused directly across many accounts. (correct answer)
  2. They prevent all offline password guesses because the attacker cannot reverse a properly generated salt.
  3. They keep the hashing algorithm secret even though the salts and password digests have been exposed.
  4. They allow the server to decrypt each password while preventing the attacker from performing the same operation.
Explanation: When a question asks what salts "still provide" after being exposed, you should focus on what problem salts were designed to solve — not what they were never meant to do. Salts exist to defeat precomputed attacks, such as rainbow tables, and to prevent identical passwords from producing identical hashes. Even when an attacker has the salt, they must conduct a fresh, targeted brute-force or dictionary attack per account — computing hash(salt + guess) for every candidate password, for every user individually. A salt stolen from account A is useless against account B because each account has a unique salt. This is exactly what A describes, making it the correct answer: salts force per-account computation and eliminate the reuse of precomputed lookup tables. B is wrong because it overclaims. Salts do not prevent offline guessing — once an attacker has the hash and salt, they can guess indefinitely offline. Salts only make that guessing more expensive and non-transferable across accounts. C is a misconception: salts have nothing to do with keeping the hashing algorithm secret. In good security design, the algorithm is assumed public (Kerckhoffs's principle), and salts provide no confidentiality for it whatsoever. D confuses hashing with encryption. Hashing is a one-way function — neither the server nor the attacker "decrypts" a password hash. Servers verify passwords by re-hashing the input, not by decrypting anything. A useful rule of thumb: salts slow and isolate attacks; they do not stop them. Any answer claiming salts fully prevent offline cracking is an overstatement and should be eliminated immediately.

Question 3

A legacy application adds one fixed, sitewide salt to every user's password before hashing. The fixed salt is stored in the application configuration. Investigators later observe that users with the same password still have the same stored digest.

Which change would most directly correct the password-storage weakness demonstrated by this observation?

  1. Move the fixed salt from configuration into the database while retaining one value for all users.
  2. Encrypt the fixed salt with the same key used to encrypt application configuration backups.
  3. Generate and store a separate salt for each password record, then include it in that record's hash. (correct answer)
  4. Replace the fixed salt whenever the application starts, without reprocessing existing password records.
Explanation: When you see a question about password storage weaknesses, the core concept being tested is salting — specifically, why salts must be unique per user to be effective. Ask yourself: "What attack does this control prevent, and does this implementation actually prevent it?" The observation that users with identical passwords produce identical digests reveals a critical flaw: a single, fixed salt is functionally equivalent to no salt at all. A salt's purpose is to ensure that even two users with the same password produce different hashes, defeating precomputed lookup tables (rainbow tables) and preventing an attacker from cracking one hash and immediately knowing every other user with the same password. When the salt never changes, it just becomes a permanent, predictable modifier — the attacker incorporates it once and the attack proceeds normally. C directly fixes this by generating a unique, random salt for each user record and storing it alongside the hash. Now even identical passwords produce completely different digests, forcing an attacker to crack each hash individually. A is wrong because moving the fixed salt to the database doesn't change the fundamental problem — it's still one value shared across all users. The storage location is irrelevant; uniqueness is what matters. B is wrong because encrypting the salt addresses confidentiality, not the architectural flaw. A shared salt that's encrypted is still a shared salt; the weakness persists even if an attacker can't directly read the value. D is wrong because rotating the salt on restart without reprocessing existing records leaves all current hashes unprotected and breaks authentication for those users — it solves nothing and creates new problems. Study tip: When evaluating salting schemes, always ask per-user uniqueness, not secrecy of the salt. A salt doesn't need to be secret — it needs to be different for every record.

Question 4

A user submits a password-change request but accidentally enters the same password currently in use. The application generates a fresh random salt whenever it accepts a password-change request and then stores a newly computed hash.

What should an auditor expect when comparing the password record before and after this request?

  1. The salt should change, but the digest should remain identical because the password did not change.
  2. The digest should change only if the hashing algorithm can recover and compare both plaintext passwords.
  3. The salt and digest should remain identical because changing either value would invalidate the same password.
  4. The salt and digest should both change, even though the same password can still authenticate afterward. (correct answer)
Explanation: When you see a question about password storage, anchor your thinking to how salted hashing actually works: a salt is random data combined with the password before hashing, and the final stored record is the pair (salt, hash). The critical insight is that these two values are computed together, so changing either input — including the salt — will change the output hash, even if the password itself stays the same. Here's the chain of events in this scenario: the application generates a new random salt, then computes hash(same_password + new_salt). Because the salt changed, the resulting digest will be completely different from the original, even though the user typed the identical password. Both the stored salt and stored digest will differ from what was there before. This confirms D as correct — both values change, yet authentication still works because the system will re-use the newly stored salt when verifying future logins. A is tempting but wrong. It assumes the digest depends only on the password, ignoring the salt. Since hash(password + salt₁) ≠ hash(password + salt₂), the digest must change when the salt changes. B introduces a nonsensical condition — hashing is a one-way function, and no standard hashing algorithm "recovers" plaintext. Comparison happens by re-hashing, not decryption. C gets cause-and-effect exactly backwards: storing a new salt doesn't break authentication; instead, it's the new salt that allows the new digest to remain valid. As a study habit, always trace the full flow — (salt, password) → hash — and remember that salts exist precisely to make identical passwords produce different digests. Any question describing a salt change should immediately signal that the digest changes too.

Question 5

A development team is comparing two salt-generation approaches. Approach 1 uses each account's username as its salt. Approach 2 generates a sufficiently large random salt for each password record and stores that salt with the record. Usernames are unique within this application but may be reused on other services.

Which assessment best explains why Approach 2 is preferable?

  1. Random salts remain secret after a database breach, whereas usernames are always disclosed to attackers.
  2. Random per-record salts reduce salt reuse across services and account lifecycles without needing to be secret. (correct answer)
  3. Random salts make hashing reversible only by the application, whereas usernames make hashes publicly reversible.
  4. Random salts prevent users from selecting the same password, whereas username salts permit duplicate passwords.
Explanation: When a question compares password-salting strategies, focus on what problem salts are actually designed to solve: preventing attackers from reusing precomputed hash tables (rainbow tables) across multiple accounts or databases. Salts do not need to be secret — they just need to be unique. Approach 2 is preferable because a freshly generated random salt per record eliminates two dangerous reuse scenarios. First, if the same username exists on another service, and both services use usernames as salts, an attacker who cracks a hash on one service instantly cracks it on the other. Second, if a username is recycled within the same application (e.g., a deleted account whose handle is reclaimed), the old and new passwords could share a salt. Random per-record salts sidestep both problems without requiring any secrecy — making B the correct answer. A is wrong because it assumes secrecy is the purpose of a salt. After a database breach, a stored random salt is just as visible to an attacker as a username. The advantage was never about hiding the salt — it was always about uniqueness. C is wrong because salting does not affect reversibility in either direction. No salting scheme makes a hash "reversible only by the application." Hashing is a one-way function regardless of the salt used. D is wrong because salts have no influence over which passwords users are permitted to choose. Password policy and uniqueness constraints are enforced at the application layer, not through salt design. Study tip: On security exams, remember that salts solve the uniqueness problem, not the secrecy problem — any answer claiming salts must be hidden is almost certainly a trap.

Question 6

An organization has legacy accounts containing unsalted password hashes. It cannot recover the original passwords and wants to migrate active users to uniquely salted hashes without forcing every user to reset immediately.

Which migration method best meets the organization's objective?

  1. Generate a salt for each legacy digest and store the salt without changing the existing digest.
  2. Use each legacy digest as the new password and ask users to submit that digest during future sign-ins.
  3. Encrypt every legacy digest with one server key and treat the encrypted value as a salted password hash.
  4. After a successful legacy login, hash the submitted password with a new salt and replace the legacy record. (correct answer)
Explanation: When migrating password storage, your goal is to reach a secure state (unique salts + strong hashes) while minimizing user disruption. The key constraint here is that you cannot recover plaintext passwords from the legacy digests — so any solution must wait for users to voluntarily provide their passwords again at login. That's exactly what D accomplishes. When a user logs in successfully using the old unsalted hash (proving they know the correct password), you now have the plaintext in memory. You immediately hash it with a freshly generated salt and overwrite the legacy record. Over time, active users migrate transparently, while inactive accounts remain on the old scheme until addressed separately. This is called an on-the-fly or lazy migration and is the industry-standard approach. A is a trap. Storing a salt alongside an unchanged digest does nothing — the hash was computed without the salt, so the salt is decorative and provides zero cryptographic benefit. You cannot retroactively salt an existing hash. B treats the hash itself as a password, meaning the hash is the secret. An attacker who steals the hash database can log in directly by submitting the stolen digest — you've eliminated the need to crack anything. C confuses encryption with hashing. Encrypting a hash adds server-side confidentiality but does not produce a salted password hash. It also introduces key-management risk and doesn't fix the underlying unsalted structure. A useful rule of thumb: if a "migration" doesn't involve the user's plaintext password at some point, it cannot properly re-hash with a salt — watch for distractors that rearrange existing digests without involving the original password.

Question 7

Two designs are proposed for a new application. Design 1 stores passwords using reversible encryption and keeps the decryption key on the application server. Design 2 stores salted password hashes and verifies submitted passwords by recomputing the hash.

Why is Design 2 generally preferable for ordinary password authentication?

  1. It allows administrators to recover forgotten passwords without requiring users to contact a help desk.
  2. It guarantees that weak passwords cannot be discovered after the user database is stolen.
  3. It supports password verification without requiring the system to recover or expose the original password. (correct answer)
  4. It removes the need to store any hashing parameters or salt values alongside each user account.
Explanation: When evaluating password storage designs, the central question is: what does an attacker gain if the database is stolen? That framing will guide you to the right answer here. Design 1 stores passwords with reversible encryption and keeps the decryption key on the same server. If an attacker compromises that server, they have both the ciphertext and the key — effectively recovering every user's original password. Design 2 stores a salted hash instead. Because hashing is a one-way function, the system never needs to reverse anything: it simply re-hashes the submitted password with the stored salt and checks whether the result matches. Verification works entirely without exposing or recovering the original password. That's exactly what C describes, and it's the core architectural advantage. A is actually describing a disadvantage of Design 1, not a benefit of Design 2. Design 2 cannot recover original passwords — if a user forgets their password, the system must issue a reset, not a retrieval. Framing that as an advantage of Design 2 is backwards. B overstates the guarantee. Salted hashes significantly raise the cost of cracking, but a weak password like "123456" can still be discovered through brute force or dictionary attacks even against a salted hash. Design 2 makes cracking harder, not impossible. D is factually wrong. Design 2 absolutely does require storing the salt (and often the hash algorithm identifier) alongside each account — that's what makes it work correctly. As a study tip: watch for answer choices that conflate "harder" with "impossible" in security questions — that overstatement is a classic distractor.

Question 8

During an audit, an administrator creates several test accounts and intentionally assigns the same password to each account. The password database stores a different salt value for every test account, but all of the accounts have the same stored password digest.

Which finding best explains the audit results?

  1. The hash algorithm is functioning correctly because equal passwords must always produce equal digests.
  2. The implementation is likely omitting the salt, or using one shared value, when computing each digest. (correct answer)
  3. The unique salts are likely encrypting the digests with the same database encryption key.
  4. The implementation is likely generating hash collisions because the account names differ.
Explanation: Whenever you see a question about password storage, anchor your thinking to how salting is supposed to work: a unique salt is concatenated with the password before hashing, so that even identical passwords produce completely different digests. The whole point of per-account salts is to defeat precomputation attacks and ensure no two accounts share the same digest — even if they share the same password. That's exactly why the audit result is a red flag. The administrator set the same password on every test account, and the database shows unique salts stored alongside each account — yet every digest is identical. If the salt were actually being incorporated into the hash computation, different salts would produce different digests. The only explanations consistent with identical digests are that the code is hashing the password alone and ignoring the salt entirely, or that it's accidentally using one hardcoded salt value for every account. Either way, B correctly identifies a broken implementation where the salt isn't being used as intended. A is a trap that sounds logical but misunderstands salting. Equal passwords should not produce equal digests when unique salts are applied — that's the entire purpose of salting. C confuses hashing with encryption; salts don't encrypt digests, and a shared encryption key wouldn't cause identical digests from a hashing function. D misrepresents hash collisions. Collisions occur when different inputs produce the same digest — a rare cryptographic failure — not a predictable outcome just because account names differ. As a study tip: remember that stored salts that never appear in the digest computation are decorative, not protective — a common implementation mistake testers love to probe.

Question 9

A help-desk tool has a button labeled "Show current password." When an authorized technician selects it, the tool displays the user's existing password rather than issuing a reset link or temporary credential.

Assuming the displayed value is retrieved from the authentication system, what is the most significant password-storage concern?

  1. The system must retain the password in plaintext or a recoverable form rather than only as a one-way hash. (correct answer)
  2. The system must use unique salts, because salts are specifically designed to reveal forgotten passwords to administrators.
  3. The system must generate a new password hash each time, because stored hashes naturally reveal their original passwords.
  4. The system must store only usernames, because password hashes cannot be associated with individual user records.
Explanation: When you see a question about password storage, anchor your thinking to one foundational principle: modern systems should never be able to reproduce a user's original password. Passwords should be processed through a one-way cryptographic hash (like bcrypt or Argon2), meaning the stored value cannot be reversed to reveal the original. The scenario is the red flag here — if a system can display a user's current password on demand, that means the system has stored something reversible: either the plaintext password itself, or an encrypted value that can be decrypted. Neither approach is acceptable. A true one-way hash is irreversible by design, so any system capable of showing you the real password is fundamentally broken in its storage model. That's exactly what A identifies — the system must be retaining the password in plaintext or a recoverable (reversible) form, which is the most significant storage vulnerability. B is wrong on two levels: salts are random values added before hashing to prevent precomputed rainbow-table attacks — they have absolutely nothing to do with revealing passwords to administrators. The definition given in option B is fabricated and backwards. C is wrong because hashes do not naturally reveal their original passwords — that contradicts the entire definition of a one-way hash. Rehashing on each login attempt is also not how stored credential systems work. D is wrong because password hashes absolutely can (and must) be associated with individual user records — that's how authentication works. This option describes a system that couldn't function at all. Your study tip: whenever a scenario shows a system revealing an existing password, immediately think "reversible storage" — that's the vulnerability, and it's always the wrong design.

Question 10

Following a database breach, a security manager states, "Every password hash had a unique salt, so even users who chose very common passwords are safe from offline guessing."

Which response most accurately evaluates the manager's statement?

  1. It is correct because a unique salt increases the possible password length beyond what an attacker can search.
  2. It is incorrect because salts separate attacks across records, but attackers can still test likely passwords for each record. (correct answer)
  3. It is correct because a salt acts as a second authentication factor that is unavailable to the password cracker.
  4. It is incorrect because adding a salt makes the stored password reversible whenever the database is compromised.
Explanation: When thinking about password storage security, you need to clearly separate what salts do from what they guarantee. A salt is a unique random value appended to a password before hashing, ensuring that two users with identical passwords produce different hash outputs. This defeats precomputed attacks like rainbow tables — but it does not eliminate the possibility of targeted guessing against individual records. This is exactly why B is correct. Once an attacker has the database, they can attack each record individually: take a candidate password (say, "password123"), append that record's known salt, hash the combination, and compare it to the stored hash. For users who chose very common passwords, this targeted per-record guessing succeeds quickly. The salt forces attackers to redo this work for each account rather than cracking all at once, but it absolutely does not make common passwords "safe." A is wrong because a salt doesn't extend password length in any meaningful security sense — it doesn't expand the search space of the password itself, only preventing cross-account attacks. C is wrong because a salt is not an authentication factor; it's a storage mechanism stored alongside the hash in the same database, so the attacker already has it. D is wrong and confused — salting doesn't make hashes reversible. Hashing remains a one-way function regardless of salting; the vulnerability is guessing, not decryption. A useful study rule: salts solve the scale problem (precomputed tables, identical-hash exposure), but only slow algorithms like bcrypt or Argon2 address the speed problem that makes common passwords crackable. Strong password storage requires both.