Message-ID: <20170317020848.GA22962@openwall.com>
Date: Fri, 17 Mar 2017 03:08:48 +0100
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] trivial delegation

On Thu, Mar 16, 2017 at 08:32:10PM +0100, Solar Designer wrote:
> In order to minimize the exposure of sensitive information to the
> server, the requesting system should include a secret in its pre-hash
> computation.  It can be a global secret (per deployment) or it can be a
> second per-account salt.  This is fine, but this extra data will then
> need to be stored somewhere, and the computation will need to precede
> our hashing scheme's computation each time, even if the delegation is
> not always used or is dismantled later.  So we can't just say that this
> e.g. yescrypt standard hash encoding includes all of the inputs to this
> hash computation (sans the password and optional encryption key) and
> that the entire algorithm is specified by yescrypt - rather, there would
> be site-specific pre-hashing algorithms (we could recommend some
> "standard" for pre-hashing, but technically it'd remain separate).
> 
> What I am thinking is that similarly to built-in server relief, we could
> instead structure the hashing scheme such that it'd include the
> separable pre-hashing as a standard step that is always done (whether
> there's delegation or not).  Then delegation-computed hashes will not
> require extra storage for an extra secret key and/or secret salt.
> 
> Specifically, it means that the main and only salt will also serve this
> purpose, and in a delegation setup will not be revealed to the server.
> The hashing scheme will then start by combining the password and salt
> inputs e.g. with HMAC, and then will never use the salt directly again.
> In a delegation setup, the requester will compute the HMAC on its end,
> send it and yescrypt parameters (but not the salt) to the server, and
> receive the hash value, which it will re-combine with the parameters and
> the salt to form a standard yescrypt hash encoding string for storage or
> comparison.

Continuing upon my half-baked thoughts above, I see two problems:

1. An attacker with oracle access to a password hashing delegation
server will be able to use this server's computing power to crack not
only the corresponding organization's password hashes, but also another
one's (which uses yescrypt too) if the attacker already has that other
org's salts (presumably along with the hashes).  This is partially
mitigated by the delegation server also using yescrypt's optional hash
encryption feature, but only until the corresponding key(s) are also in
attacker's possession (and moreover, precomputation can start before).

For this reason, a delegation setup must use an org specific local
parameter, so that the delegation server would not compute hashes usable
for (or rather against) another org (that this server wasn't meant to
service).  A yescrypt ROM could be it, but it's optional and it would be
shared in a password hashing outsourcing setup (where a delegation
server would be shared by more than one org).  A small local parameter
wouldn't have to be shared across orgs in a setup like this, although
all of the whitelisted ones would still be usable in an attack.
Nevertheless, they'd limit the orgs which may be attacked and they'd
provide accountability and perhaps per-org rate limiting (an org is not
supposed to compute more than 1 million hashes/day? so don't let them
nor their attackers do it).

The small local parameter provides different security than an encryption
key does in that even if this parameter is available to an attacker, the
attacker still can't force the delegation server to hash passwords for
that org yet disguise their activity against another org's credentials
and rate-limiting.  That's because the parameter is an inherent part of
the hash computation, rather than something that can be removed and
re-added (like encryption is when keys are known).

So yescrypt will have to accept an extra (or not really, see below)
parameter, and the systems using this delegation service will need to
store this parameter somewhere at least if they don't always or no
longer use delegation - so we're back to the original non-elegance we
had with password hashing schemes lacking builtin support for what I
call trivial delegation here.  I guess we should just accept this.

Implementation-wise, this extra local parameter supporting delegation
could simply be yescrypt's salt.  The per-account salts would already
have been applied by the requesters, leaving yescrypt's salt input
available for such reuse.  It's non-elegant not to have actual
per-account salts encoded where they normally are in yescrypt hash
encoding strings, instead having to store them separately (well, or
mangle the strings, but then they no longer correspond to usual yescrypt
hash encodings semantically even if they do syntactically).  Yet on its
own that's probably not enough of a reason to introduce any special
support for delegation.

2. Some delegation users would inevitably mix things up, e.g. swap the
password and salt inputs to HMAC, resulting in hashes that look like
yescrypt but are not computable by full yescrypt with any pre-hashing.
That's worse than simply having the pre-hashing for delegation separate
from the entire yescrypt computation, in which case it can always be
done before computing yescrypt even when delegation is no longer in use.

This second problem may also apply to server relief if it's used when
setting new passwords.

Alexander

Powered by blists - more mailing lists