Why should old passwords be changed after switching from a fixed salt to a random salt in PBKDF2?

PT0-002 By islever Editorial Last updated

Short answer

A Changing passwords that were created before this code update

Question

A penetration tester discovered a code repository and noticed passwords were hashed before they were stored in the database with the following code: salt = 'saltl23' hash = hashlib.pbkdf2_hmac('sha256', plaintext, salt, 10000) The penetration tester recommended the code be updated to the following: salt = os.urandom(32) hash = hashlib.pbkdf2_hmac('sha256', plaintext, salt, 10000) Which of the following steps should the penetration tester recommend?
  1. Changing passwords that were created before this code update Correct Answer
  2. Storing hashes created by both methods for compatibility
  3. Rehashing all old passwords with the new code
  4. Updating the SHA-256 algorithm to something more secure

Key Takeaways

The exam tests your understanding that password hashes are one-way, and a salt change only affects future hashes; old hashes remain vulnerable, so the only safe step is to expire old passwords.

This PT0-002 question explains why switching from a fixed salt to a random salt in PBKDF2 requires forcing a password reset for existing users. The community consensus is that old hashes cannot be rehashed without plaintext, so the correct recommendation is to change passwords created before the update.

Common mistake: Choosing C (rehashing all old passwords) is the most common mistake because it assumes the original plaintext is still known, but hashes cannot be reversed or rehashed without the plaintext password.

Expert Analysis

Why the Answer Is Correct

The original code uses a fixed salt 'saltl23', which is predictable and vulnerable to rainbow table attacks. Updating to os.urandom(32) creates a unique random salt per password. However, existing hashes were created with the fixed salt and remain weak because they are all salted identically. Since hash functions are one-way, you can't rehash old hashes; you need the user's plaintext password to generate a new hash. Therefore, the correct step is to force a password change for all users whose accounts were created before the update.

Why the Other Options Are Wrong

B (storing both methods) is not necessary and would leave weak hashes in the database, continuing risk. C (rehashing all old passwords) is impossible without plaintext, as comment [2] notes. D is irrelevant because SHA-256 with PBKDF2 is acceptable; the issue is the fixed salt, not the algorithm strength. Comment [1] also states the other options are not valid steps.

Community Comment Notes

Comment [1] supports A and explains that old passwords need to be changed to be hashed with the new salt. Comment [2] correctly points out that without original plaintext, rehashing is impossible because hashes can't be reversed. Comment [3] echoes that C is wrong for the same reason. The community is unanimous (A with 100 votes).

Official Reference

These links open the official vendor documentation in a new tab.

Exam Strategy

When a question asks about updating password hashing, always consider whether old hashes can be migrated. Remember that hashing is irreversible, so any change to the salt or algorithm requires the original plaintext, which is only available at login—therefore, the standard solution is to force a password reset.

Community Votes

A
100%

100% of anonymous learners picked answer A. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 3 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 3

  1. IamBlackFire 👍 2 Answered A
    The penetration tester recommended the code be updated to use a random salt instead of a fixed salt for hashing passwords.Therefore, the penetration tester should recommend changing passwords that were created before this code update, so that they can be hashed with the new salt and be more secure. The other options are not valid steps that the penetration tester should recommend. Keeping hashes created by both methods for compatibility would defeat the purpose of updating the code, as it would leave some hashes vulnerable to attacks. Rehashing all old passwords with the new code would not work, as it would require knowing the plaintext passwords, which are not stored in the database. Replacing the SHA-256 algorithm to something more secure is not necessary, as SHA-256 is a secure and widely used hashing algorithm that has no known vulnerabilities or collisions.
  2. sparseyyy 👍 2 Answered A
    Without the original plaintext passwords, it's impossible to rehash old passwords. You cannot reverse a hash to get the plaintext password, so users will need to reset their passwords.
  3. wdmssk 👍 1
    A C is wrong: Without knowing the original plaintext password, rehashing old passwords is impossible.

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Which Post-Report Activity Prevents CISO Disputing Finding Validity?

S-grade

How should penetration testers prioritize findings in a report?

S-grade

Which agreement did a pen tester breach by requesting a CVE without authorization?

S-grade

Which Tool Best Detects Vulnerabilities on a Database Server?

S-grade

← Back to PT0-002 Study Guide