>
> a. Make the passphrase hash expensive. There are lots of
> ways to do this. Users shouldn't mind a half-second delay
> for hashing their passphrase, but this will make dictionary
> attacks much harder to mount.
Right, though of course Moore's Law will tend to erode this over time
if it's simply CPU-intensive. Use a scheme that lets you adjust it with time.
For example, if you're simply iterating a hash function, store the count with
the password, and let the adminstrator increase it for new passwords as needed.
>
> b. Use a unique per-passphrase salt of at least 32 bits.
>
Why 32 bits? Salts are good, and often cheap, but I'm curious what your
rationale is. Traditionally, a salt serves two purposes: to increase the
expense (CPU and storage) of precomputing a dictionary, and to make it harder
to find two passwords with the same salt. UNIX uses a 12-bit salt, which is
often quite sufficient. Given a million-entry dictionary, and using your
number of .5 seconds/guess, with no salt at all it would take ~139 hours to
precompute the hash of all guesses. Clearly, that's too low. But 4096*139
is ~24000 days. Granted, that process can be parallelized, but it's still
a lot of computing -- 240 days for a hundred machines crunching.
That number is still too low for long-term safety of a password used for
secrecy, rather than login. But it's far from clear to me that one needs
to go to 32 bits, if that process is at all expensive. (UNIX implemented
its salt by swapping entries in the E-box of DES. That's not a scheme that
scales well to a bigger salt. Note, though, that it also had the advantage of
ruling out the use of stock DES chips for password-guessing.)
