1
$\begingroup$

Let's say I encrypt my passwords with PBKDF2 and store it somewhere. Now let's say it was stolen and the hacker, who stole it knows it was hashed with PBKDF2.

Does a knowledge of number of iterations make it easier to brute force the password? Reasons?

Improve this question
$\endgroup$

2 Answers 2

Reset to default
3
$\begingroup$

Normally we store the number of iterations with the hashed password. In the same string actually. This allows us to upgrade the number of iterations in a running system and in an interm phase have different passwords with different number of iterations.

If however you tried to keep the number of iterations secret, an attacker who knows the password for a single account could easily discover the number of iterations.

If we really can't tell the number of iterations an attacker would need to assume an upper bound and both do more interm checks but more importantly may continue longer then needed if his upper bound isn't tight.

I do not recommend trying to hide this information.

Improve this answer
$\endgroup$
2
  • 1
    $\begingroup$ One of the basic principles of cryptographic systems is that the amount of data which needs to be kept secret should be minimized. In a password hashing scheme that means the plaintext password and possibly a "pepper" are kept secret, but adding more secret values is just a way to complicate implementation. KISS applies - you can gain more by using a longer salt than keeping the iteration count secret, and with less effort. The underlying system is also probably only designed to keep the plaintext (and pepper if supported) secret, so one should assume that it will leak the iteration count! $\endgroup$
    – SAI Peregrinus
    Jul 16, 2018 at 20:33
  • $\begingroup$ One used a random salt, different for each hash. This knowing one hash does not reveal the password associated with other hashes. Further including the iterations with the hash allows changing the iteration count for future password hashes if necessary. $\endgroup$
    – zaph
    Jul 16, 2018 at 22:25
1
$\begingroup$

Let's say I encrypt my passwords with PBKDF2 and store it somewhere.

It's not clear here whether you literally mean to encrypt some passwords with a key derived from a master password (as a password manager does), or whether you've hashed a password and stored the salt and hash as a verification token.

Does a knowledge of number of iterations make it easier to brute force the password?

Not really. The reason is that PBKDF2, at its guts, has this structure:

$$ F(\mathrm{Password}, \mathrm{Salt}, c, i) = U_1 \oplus \dots \oplus U_c $$

...where $c$ is the iteration count, $i$ the output block, and:

$$ \begin{align} U_1 &= PRF(\mathrm{Password}, \mathrm{Salt}\, \|\, \mathrm{INT\_32\_BE}(i)) \\ U_2 &= PRF(\mathrm{Password}, U_1) \\ & \vdots \\ U_c &= PRF(\mathrm{Password}, U_{c-1}) \end{align} $$

Since the sequence of PRF outputs $U_i$ and their XORs share prefixes for any two values of $c$, this means that between each iteration the attacker is able to interleave a test to see whether their current password guess + trial iteration count succeeds. If it doesn't, they can resume the PBKDF2 computation without paying the cost of the earlier iterations. So the attacker is only slowed down by:

  1. How much they overestimate the upper bound of the true iteration count;
  2. The cost of the test decryptions at each iteration.

These are only going to make the attacker's cost incrementally larger.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.