Re: Best practice for password hashing



On 2010-06-08, Datesfat Chicks <datesfat.chicks@xxxxxxxxx> wrote:
"Carsten Krueger" <cakruege@xxxxxxxxx> wrote in message
news:7eybrva607il$.dlg@xxxxxxxxxxxxxxxxxxxxxx
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
passwords).

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


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

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.

Datesfat

.



Relevant Pages

  • Re: Newbie - Is this Reasonable?
    ... because this hash is stored in the database. ... So you use PKCS5v2 to generate a key hash from a salt and the user's passphrase, then store the salt and the hash in a database. ... are even more critical in database applications because the payoff from tampering with selected fields may be much higher, fields tend to be fixed-length so it's easier to tamper with them in a meaningful way, and databases lend themselves to off-line analysis, so the attacker can marshall more resources and take more time to attack your system. ... You're using a stream cipher for encryption. ...
    (sci.crypt)
  • Re: Best practice for password hashing
    ... unless there is a database compromise. ... The most common scheme is never to store passwords, but to instead store a cryptographic hash of the password. ... That way, if the base machine is compromised, they can't guess very rapidly unless they can compromise both machines. ...
    (sci.crypt)
  • Re: Secure Password in database
    ... Subject: Secure Password in database ... > in database as SHA hash. ... You don't want to be able to compromise the client, ... get a bunch of garbage back when you try to get the 2-way encrypted data. ...
    (SecProg)
  • Re: Best practice for password hashing
    ... 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. ... If 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. ...
    (sci.crypt)
  • Re: Email encryption
    ... Into a system file. ... If the attacker can get your database, what prevents him from also getting ... One possible approach is to hash the contact address using a one-way ...
    (sci.crypt)