Subject: [http-auth] [Mutual] answers for FAQs (3) list of pwd-hash and possible use for PBKDF2

From: Yutaka OIWA <[email-masked]>
Date: Fri, 4 Oct 2013 08:55:37 +0900

Dear all,

The third thing to answer is about pwd-hash list in Section 4.1.
Our proposal have a pwd-hash parameter for additional hashing of
passwords, and that have only choices from none, md5, digest-md5 and sha1.
As reviewers guessed (and we also mentioned in Section 16.4),
this facility is only for legacy migration of old password databases.
We recommend, in Section 16.4, to use "none" setting as much as possible.
We considered several PHP-based authentication implementation,
as well as the existing Digest password database as migration targets.
That's why we do not include SHA-256 and any other decent algorithms,
simply because it is not used.

Internally, we have another true layer of password hashing (with using
user names as salts) in Section 11.2, function pi, which uses
SHA-256 or SHA-512 (for schemes defined in -algo draft).

If people think we do not need any support for such old-dated database,
I'll simply drop the pwd-hash feature entirely.  For this feature I do not
have very strong opinion for keeping it.

As a similar but independent topic, we consider introducing another into here.
It seems to be a good idea to use PBKDF2 (RFC 2898) or similar functions
for password hashing.  It may greatly slow down the attack on the
password database stolen from the server side.
I need more opinions about (for or against) such computational (rather ad-hoc)
hardening against off-line password cracking using server-leaked information.
If doing so, I'll introduce it as a replacing "pi" function in Section 11.2,
instead of as a choice for "ph" function in Section 4.1.

However, we might be careful about that, in our scheme, the actual
mechanism for hardening the attacks may slightly different from those
expected by the design of those functions.
In general use case, the leaked information is the output of PBKDF2,
and the information which attackers want to acquire is the plain-text passwords.
In our case, the leaked information is the PBKDF2 output further
encrypted (hashed) with discrete-logarithm-based one-way function,
and the attack target will be the output of PBKDF2, not the raw password.
Of course, the most feasible way of such cracking is guessing the password,
(the other is the exhaustive search on output space of PBKDF2 which is
infeasible)
so attackers will have to compute PBKDF2 so many times, as similar as
the general use case scenario.

-- 
Yutaka OIWA, Ph.D.                 Leader, System Life-cycle Research Group
                               Research Institute for Secure Systems (RISEC)
     National Institute of Advanced Industrial Science and Technology (AIST)
                       Mail addresses: <[email-masked]>, <[email-masked]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]