Message-ID: <20160323130918.GA6412@bolet.org>
Date: Wed, 23 Mar 2016 14:09:18 +0100
From: Thomas Pornin <pornin@...et.org>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] hash encryption

On Wed, Mar 23, 2016 at 09:45:10AM +0100, Krisztián Pintér wrote:
> what is the rationale to encrypt the hash?

Though I do not know exactly why Alexander adds such a support, I
know of a rationale for that.

On a system that verifies user passwords for authentication, we need to
store "something": a data element that necessarily allows for offline
dictionary attacks, should it be revealed to attackers. We use
password hashing functions, with all the configurable slowness and
salts, precisely so that such dictionary attacks are made expensive for
attackers.

Now, it so happens that some common methods by which attackers can learn
password hashes are limited in scope. If the attacker steals a complete
backup of the machine, he gets all the data; but if he uses a SQL
injection, then he may get a read access to the server's database only.
Hence the idea of using, in the password hashing process, an additional
secret key that will not be stored in the database (in practice, it
would be in a configuration file on the application server). We
basically want a key K such that:

 -- dictionary attacks are not feasible without key K;
 -- if K is revealed, the security properties of key-less password
    hashing are maintained.

Adding a secret key has sometimes been called "peppering" (as a bad pun
on "salts"). The point of peppering is to try to have better resistance
to attackers who get a partial read-only view of the server's storage;
we also want the secret key to be, indeed, a fixed secret key, because
it will be stored outside of the normal server storage area (the
database) so it should be small and not change. Peppering has its own
drawbacks (it entails key management and associated process for
generation, storage, backup...) but I can understand its appeal. It is a
trade-off between ease of implementation and maintenance, and extra
security in a situation that can plausibly happen (that is, until Web
developers finally learn that SQL prepared statements should always be
used, dammit).


There are basically four ways to do some peppering over an existing
password hashing function:

 1. Encrypt the password with key K, then hash the encrypted password.
 2. MAC the password with key K, then hash the MAC output.
 3. Hash the password, then encrypt the hash output with key K.
 4. Hash the password, then MAC the hash output with key K.

What Alexander wishes to implement is method 3. Among all four methods,
it is the one which is most easily applied to, and removed from, an
existing system. For the core functionality of verifying passwords,
they are equivalent, but for maintenance, they somewhat differ:

 -- Method 3 and 4 can be applied to an existing set of key-less
 password hashes; methods 1 and 2 cannot (if we want to pepperize an
 existing system with methods 1 or 2, then we must wait for users to log
 on and apply the encryption or MAC at that moment).

 -- Methods 1, 2 and 3 allow for offline work factor increase. If the
 password hashing function has such a feature, and you wish to increase
 the work factor because you bought a faster server, then you can do so
 in a night batch. With method 4, you have to wait for the individual
 users to log on, and do the work factor increase gradually.

None of these elements is really crucial, but I understand that
Alexander would prefer encryption of the hash, since it is the one that
keeps most options open.

Personally I tend to favour MAC-based constructions, because the MAC is
a no-brainer: just use HMAC. HMAC requires no IV and thus has no
catastrophic failure mode (contrary to UMAC or similar systems where IV
reuse is a capital sin); HMAC is also quite tolerant to key reuse (using
the same key for encryption and MAC is not recommanded, but in practice
HMAC will resist such abuse). It is quite hard to get HMAC wrong.


	--Thomas Pornin

Powered by blists - more mailing lists