Will obtaining password hash compromise derived encryption key?

Question

I've been looking at how PBKDF is used to generate encryption key for AES. One thing I couldn't get my head around is that how those OS keep the encryption key safe apart from using hardware modules.

So far my understanding is that OS like Windows stores user hashed user password in a file (SAM file). The password hash is then used to generate the encryption key for applications which need to encrypt data. THis is done in DPAPI and applications can just call the API and the system library will automatically extract the user password (hashed) from current context and derives a key from it (in a simple way,maybe more complicated than this). But how does windows ensure the safety of encryption key, even if the key is only generated on the fly, as long as the attacker obtains the hash, wouldn't it compromise the encryption key in someway as they can apply the same PBKDF2 (provided if they somehow can try those with possible cases).

If an attacker grabs the windows password file and extract the hash out of it (this shouldn't be too hard), is he able to apply PBKDF2 (or any possible derivation function) on top of it to get the encryption key? . Is it some hard-coded salt value when the PBKDF2 is applied to the hash in windows's source ?

Thanks

Answer 1

If encryption key can be derived using only data persisting in the user database (like user name and password hash for example) that would constitute a major design flaw for the reasons you describe above: original secret (user password) is not needed to derive key and access encrypted data.

The way Windows prevents this from happening (or at least the way it is supposed to, see this for more details) is by using different hash algorithms for password hashing and key derivation: passwords are hashed using NTLM hash (which is MD4) and keys are derived from user's password using PBKDF2-SHA1. This way obtaining hash of the password won't immediately enable attacker to compute encryption keys because the original password is needed to compute the key.

New systems shouldn't normally use plain unsalted hashes for password hashing; instead something like bcrypt or scrypt is a more robust alternatives.

If system is constrained and it's beneficial to use PBKDF2 for both password hashing and key derivation, one can use different salts for different purposes: one for password hashing and verification, another for key derivation; in this case compromising password hash won't immediately enable attacker to compute derived key as the salt is different and original password is still needed to compute PBKDF2 with another salt value.