lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
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