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 ?


1 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.

  • The windows derive key directly from the password hash rather than from the original password - according to the article you linked.
    – grumpynerd
    Commented Aug 3, 2014 at 10:50
  • The thing that maybe vulnerable is the password hash that is going to be used to derive the key, if the attacker obtains this hash, can't they just run through all possible PBKDF to generate possible encryption key?
    – grumpynerd
    Commented Aug 3, 2014 at 10:55
  • What matters is what hash algorithm is used key derivation. If it's MD4 one then system is vulnerable because this hash is stored in SAM. If it's SHA1 (or MD5, or anything else – just not MD4) then it's OK (well, more or less) because there's no way to compute SHA1 (or MD5, etc) of a password given only MD4 of that password.
    – Andrey
    Commented Aug 3, 2014 at 11:02
  • i think i sort of understand what you are saying, I thought they just grabbed the password hash from SAM to derive the key always. But where else could they get the original password from? AFAIK, windows don't store plain password right? then how could they apply a SHA1 over a original password if they don't get it from SAM???? Or they could store the SHA1(password) in another file ? or cache it in memory after they login? but as long as the attacker know where it is, they can just grab it and used it to derive the key can't they?
    – grumpynerd
    Commented Aug 3, 2014 at 11:18
  • Correct, password (or derived key) is cached in memory as long as the user is logged in. Attacker with proper access can dump it from RAM. Note that this is much better than what you describe in OP (extract key material from SAM) because: (a) password or key is in RAM only as long as user is logged in; (b) attacker needs some sort of online access to the system (as opposed to just taking hard drive out and reading SAM).
    – Andrey
    Commented Aug 3, 2014 at 12:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .