[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180323215321.GA23360@openwall.com>
Date: Fri, 23 Mar 2018 22:53:21 +0100
From: Solar Designer <solar@...nwall.com>
To: passwords@...ts.openwall.com
Subject: Re: keyed hash vs. encryption
On Thu, Mar 22, 2018 at 08:40:57PM -0400, Arnold Reinhold wrote:
> the processing time savings in using a simple hash protected by a hardware secret vs using an open resource-intensive hash could be important in making the switch to an HSM scheme more attractive economically.
I think it's never a good idea to completely give up on costly hashing
when starting to use an HSM. Having more than one iteration of a crypto
primitive and/or using some memory (rather than almost none) is always
affordable, and even more so when the total budget is sufficient to
include HSMs. There's no point in being able to compute those hashes
e.g. in a microsecond (thus, millions per second per server) instead of
a millisecond (e.g. per hardware thread, meaning tens of thousand per
server per second). "Costly" hashing doesn't have to mean extra
hardware is being deployed just for that task - it should mean at least
that the hardware that would be deployed anyway is put to proper use.
FWIW, I'm currently consulting on a deployment involving yescrypt and
HSMs at once, to have some defense-in-depth.
> I'd like to hear the case for continuing to use an open hashing schemes to protect passwords long term.
There's a cost in acquiring, deploying, and properly managing HSMs, and
having proper backups. Someone e.g. with a WordPress blog on shared
hosting wouldn't deploy an HSM. (However, we're considering offering a
related post-hashing service over the Internet, where the hash
encryption key would not be on the customer's server, nor on their web
hosting provider's.)
Edit: you actually mention "smaller systems" as an exception closer to
the end of your message.
> Given the massive growth in computing power associated with GPUs, crypto mining and botnets,
yescrypt has measures against GPUs and botnets.
Notice how the 8 or so cryptocoins that currently use an old revision of
yescrypt (from 2014) at a mere 2 MiB (~10k h/s on a 16-core server, ~20k
on a modern 28-core, which is about the max you could need for password
hashing) and have proof-of-concept GPU miners developed for them are
still more efficient to mine on CPU than on GPU.
As to botnets, that's where yescrypt's optional ROM helps, with the ROM
intended to be larger than most botnet nodes' RAM sizes for a few years
into the future.
Cryptocoin mining isn't really a threat to password hashing yet. There
are known cases (at least not to me) of cryptocoin miner ASICs being
applied to password hash cracking yet. They tend to be unsuitable,
sometimes for obvious and sometimes for more subtle reasons. It could
be on-die comparison for "< target", extremely low external bandwidth,
hard-coded scrypt r=1 like scrypt-based cryptocoins use (whereas
password hashing and KDF uses of scrypt use r=8 or similar, and
supporting r > 1 would make those ASICs worse at their primary intended
purpose). Also, while scrypt in particular is designed to be
TMTO-friendly (meaning that even an scrypt ASIC with tiny on-die memory
and low external bandwidth can compute scrypt hashes for high N, albeit
slowly, if configurable at all), Argon2 and yescrypt are designed to be
TMTO-resistant (meaning that such an ASIC would be limited to whatever
memory it has or/and to its external bandwidth).
> is it realistic to expect any open KDF to protect a user-selected 8 character password (the 63b minimum)?
Yes, but need to clearly understand what kind of adversaries the
protection is from, for how long, whether the attack is targeted or not
(and how many other salts the effort would be split between), and what
risk of the password falling to the attack is acceptable. And then it's
good to also use HSMs or the like.
> At the least, one would need guidelines on the minimum work factors needed (iteration count and memory) that would increase over time.
Yes, need guidelines, but those depend more on what's affordable on
given hardware. The defenders should do at least what they can with no
or little extra cost.
> In 2014 I had to increase the recommended size of a Diceware passphrase from 5 to 6 words. Five words were already more than most users find acceptable.
That's a result of unnecessarily fast/cheap password hashing. For
example, current passwdqc defaults are at 3 words with 2 separator chars
inbetween them, which is 47 bits total. (And generated passwords is a
rare case where it's actually correct and relevant to measure them in
bits of Shannon entropy, as long as the distribution is uniform, which
it must be anyway.) This is supposed to still be way more than enough
for resistance to typical non-targeted attacks on typical online
accounts, as long as currently up-to-date costly hashing is used. It's
even still enough for bcrypt, and that's a password hash from 20 years
ago, although it's indeed possible to attack bcrypt fast(er) on ASICs
(there's just little incentive still), so reliance on bcrypt is rather
short-term now. (PBKDF2-HMAC-SHA* doesn't fare nearly as well, because
of being GPU friendly. bcrypt is GPU unfriendly, although with latest
NVIDIA Volta GPUs no longer to an extent that it used to be.)
You could also be targeting a different use case, such as disk
encryption, where your users would reasonably expect a targeted attack,
if at all.
> As 63b says, with hardware secret password hashing ???brute-force attacks on the hashed memorized secrets are impractical as long as the secret salt value remains secret.??? Enterprises should not keep burdening the user to solve a problem that the enterprise itself could solve with the right technology.
I agree. It's wrong to force strict password policies onto users
without having done whatever can affordably be done server-side, and
then hopefully a more relaxed policy can be used.
> Resource intensive hashes will still be needed for applications such as disk encryption, master passwords for password managers, and for securing smaller systems. But for logging into large IT systems, given that we have a solution that can end the password arms race, it's time to move forward.
I doubt it'll fully end the arms race (HSMs are not flawless, nor are
humans who use them), but yes.
> What do we have to do to facilitate that process? A meeting perhaps?
I do my part e.g. with this slide from 2012:
http://www.openwall.com/presentations/Passwords12-The-Future-Of-Hashing/mgp00071.html
and now with the hash encryption support built into yescrypt, which
isn't exactly an HSM, but should help when dedicated authentication or
password hashing servers are used. (So the key is not in a database,
and isn't on unrelated servers.)
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
