Problem - Kevin Tafuro

}
CryptReleaseContext(hProvider, hKey);
return bResult;
The salt is used to prevent against a dictionary attack. Without salt, a malicious system
administrator could easily figure out when a user has the same password as
someone else, and he would be able to precompute a huge dictionary of common
passwords and look to see if the user’s password is in that list.
While salt is not expected to be private, it still must be chosen carefully. See Recipe
4.9 for more on salt.
How Many Iterations?
To what value should you set the iteration count? The answer depends on the environment
in which you expect your software to be deployed. The basic idea is to increase
computational costs so that a brute-force attack with lots of high-end hardware is as
expensive as possible, but not to cause too noticeable a delay on the lowest-end box on
which you would wish to run legitimately.
Often, password computations such as these occur on a server. However, there are still
people out there who run servers on their 33 MHz machines. We personally believe
that people running on that kind of hardware should be able to tolerate a one-second
delay, at the very least when computing a password for a modern application. Usually,
a human waiting on the other end will be willing to tolerate an even longer wait as long
as they know why they are waiting. Two to three seconds isn’t so bad.
With that guideline, we have timed our PKCS #5 implementation with some standard
input. Based on those timings, we think that 10,000 is good for most applications,
and 5,000 is the lowest iteration count you should consider in this day and age.
On a 33 MHz machine, 10,000 iterations should take about 2.5 seconds to process.
On a 1.67 GHz machine, they take a mere 0.045 seconds. Even if your computation
occurs on an embedded processor, people will still be able to tolerate the delay.
The good thing is that it would take a single 1.67 GHz machine more than 6 years to
guess 232 passwords, when using PKCS #5 and 10,000 iterations. Therefore, if there
really is at least 32 bits of entropy in your password (which is very rare), you probably
won’t have to worry about any attacker who has fewer than a hundred high-end
machines at his disposal, at least for a few years.
Expect governments that want your password to put together a few thousand boxes
complete with crypto acceleration, though!
Even with salt, password-guessing attacks are still possible. To prevent against this
kind of attack, PKCS #5 allows the specification of an iteration count, which basically
causes an expensive portion of the key derivation function to loop the specified
number of times. The idea is to slow down the time it takes to compute a single key
Deriving Symmetric Keys from a Password | 141
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.