Re: Best practice for password hashing

On 2010-06-08, Datesfat Chicks <datesfat.chicks@xxxxxxxxx> wrote:
"Carsten Krueger" <cakruege@xxxxxxxxx> wrote in message
Am Mon, 7 Jun 2010 23:41:17 -0700 (PDT) schrieb Paul Johnston:

Is there any guide on which is best to use?

PBKDF2 is industrie standard (has it's own RFC).

If I'm understanding this discussion, there are three different approaches
being discussed:

a)Making the hash expensive to calculate.

This is protection against brute force cracking.

b)Using salt to make dictionary attacks infeasible.

This is protection against precomputed dictionary attacks.

c)Using a hidden salt or hidden basis value (that won't be revealed if the
database is compromised because it exists outside the database) so that an
attacker is missing a piece of the information required to calculate the
hash at all (which renders compromise of the database irrelevant because the
hash stored there won't make an attack cheaper than just trying random

Not sure what this protects against. And it is dangerous. If it is
stored on another machine suddenly this machine becomes useless if the
otehr machine goes down or is disconnected. Not good. If it is on the
machine, it is a "single point of failure" in that someone, somehow
getting ahold of that secret suddenly renders this protection useless.
And since that secret is reused and must last for years, the chances of
that failure grow. Ie, while it does offer some protection it is an
unknown protection ( it could be zero) and should therefor be regarded
as offering no protection at all.

I think you can actually combine all three approaches without a problem. If
the PBKDF2 algorithm allows very long passwords, you can just append the
"hidden basis value" to the user's password before starting the algorithm.

If the database is compromised (and only the database is compromised), the
attacker won't be able to make the mapping from password to hash at any
cost, which renders compromise of the database irrelevant.

As an example, assume you store the value
"1983649812364981236401230647123656123094601237" outside of the database
(perhaps on another server, perhaps via another mechanism).

If the user's password is "cat", then the password you'd use for input to
the PBKDF2 algorithm is "cat1983649812364981236401230647123656123094601237".

If the database is compromised, the attacker won't have the string
"1983649812364981236401230647123656123094601237", so the attacker can't make
the mapping from "cat" to the hash.

Compromise of the database is then irrelevant.

compromise of that "secret" is even more probable than compromise of the

I've always used (b) and (c), and I'm not claiming that I'm a skilled web

You've discussed (a) and (b).

(a) is new to me.

It was there already in the old unix des based hash ( 25 encryptions of
the number 0 using the password as the des key-- which was why the
password was limited to 8 ascii characters). That repetition had the
purpose of slowing down repeated attempts (25 was chosen because it
would take a "long time" on the machines in the 80s. The newer MD5 based
hashes do the same thing, with additional time taking shiffling around
of the output of one run to produce the input to the next.

But (a), (b), and (c) can be combined I believe.

While c adds some security, it is really an unkown amount and could be 0.