Is there a security risk associated with using a PBKDF for an AES encryption key and Sha256 for a hash using the same password text?

Question

I am writing an encryption program using C#. My goal is to secure files even if the computer is stolen and somehow logged into.

Assumptions

• The code used to write the program is visible to a malicious user
• The password hash used in the program's login process is also visible

Concerns

• I am using the same password to:
  1. Derive an AES encryption key using Rfc2898DeriveBytes
  2. Login to the software by comparing a stored SHA256 hash
• I don't know if the stored hash can be used to figure out the encryption key

Notes

I use two different salts: one for the hash and the other for the key. I'm not sure if this really helps though because they are both stored in plain text along with the user's password hash.

Does using a PBKDF and a SHA256 hashing algorithm on the same password text present a security risk in a single computer application?

Answer 1

Yes, using a PBKDF and a SHA-256 hashing algorithm on the same password negates the usefulness of the PBKDF, by allowing to test a candidate password using a single hash; and (assuming unsalted password hash, which is not the case in the question) amortizing across multiple users/instances the computation of a rainbow table allowing to find the password quickly if its hash has been precomputed.

To make an analogy, imagine two safes, each with a 3-digit combination lock, and known to use the same 3-digit code. One safe contains valuables and uses a timed lock, preventing trying codes faster than one per hour; the other safe contains nothing and uses a non-timed lock. That second lock negates the benefit of the first one being timed, by allowing to quickly find the code for the first safe and extract the valuables.

With the unsalted SHA-256 of a mild password, a kid with a brain and web browser cracks it. Add some computing power, and the salted hash can be broken. Ask 10 random humans to pick a password they can remember a week later, and I bet at least one password succumbs to that attack.

While Rfc2898DeriveBytes is last century's password hashing / key stretching, it is still much less bad than plain hashing is. The order of magnitude of how less bad is the IterationCount parameter (and if there's no salt to the plain hash: times the number of users that an adversary is content cracking the password of).

For more efficient key stretching often available in practice, consider bcrypt or scrypt.