Message-ID: <20160324201700.GA12935@openwall.com>
Date: Thu, 24 Mar 2016 23:17:00 +0300
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] hash encryption

On Wed, Mar 23, 2016 at 02:09:18PM +0100, Thomas Pornin wrote:
> 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.

Thank you for posting this, Thomas!  This is part of my rationale.

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

This is a common scenario, yes, but there's another scenario I am
targeting first: a larger deployment, where multiple machines (or even
multiple clusters, possibly in multiple datacenters) are involved.  With
the secret being only on authentication servers (or even on dedicated
password hashing servers, with the database not directly accessible from
those servers), the compromise scenarios where an attacker will have
only the database or only the secret, but not both, are not limited to
SQL injections and the like, but also include native code execution on
or having copies of backup dumps of just some of the machine types.

> 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:

There may also be a need to re-encrypt to a different key.  This is
removing and then re-applying the encryption.

For example, this is needed when merging two databases of yescrypt
hashes, which originally used different keys, without having to store
a key ID along with each hash.

Changing the key may also be needed if the old key somewhat likely got
compromised, so that newly set passwords are not put at unjustified
risk by continuing to use the same key (and so that key IDs don't have
to be stored per-hash), as well as so that full database leaks that
occur after the key change are not affected by the previously
compromised old key.  (Only leaks of old backups of the database would
still be affected.)

> Personally I tend to favour MAC-based constructions, because the MAC is
> a no-brainer: just use HMAC.

This was my favorite choice for this purpose a few years ago, but I've
since realized how important the advantages in maintenance are from use
of encryption, and how they may translate to improved security too.

Alexander

Powered by blists - more mailing lists