[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <710CABB5-09A3-4CAC-8ADF-B4C42A321BC1@me.com>
Date: Tue, 27 Mar 2018 18:42:15 -0400
From: Arnold Reinhold <agr@...com>
To: passwords@...ts.openwall.com
Cc: Solar Designer <solar@...nwall.com>
Subject: Re: keyed hash vs. encryption
> On Mar 23, 2018, at 5:53 PM, Solar Designer <solar@...nwall.com> wrote:
>
> 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’m all for “belt and suspenders” solutions, especially in the early stages of new technology adoption, but ideally both the belt and the suspenders should each be able to hold up your pants by themselves. This means that any hash component must take significant resources to contribute meaningfully to the defense in depth. For now that’s fine, in the future the tradeoff can be revisited.
>
>> 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.
Right. I am focused on requiring hardware solutions large, high-value systems. NIST SP 800-37-3 discusses criteria for assessing the risk of a system, and I am concerned with large systems at the higher risk levels. Not only are smaller systems less able to afford a hardware solution currently, but they are often in a better position to select high work factor settings with resource intensive hashes, because login frequency is not that high. A few seconds of processing at login could be acceptable. So I don’t see solutions like yescrypt going away in the future. And in the near term, yescrypt is deployable off the shelf to gain a large security improvement, while HSM solutions may not be fully ready yet.
>
>> 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).
All good stuff, but it’s still an arms race, with the defenders at a long term disadvantage. The problem I see with cryptocoin mining, in particular, is the ecosystem that is developing, fueled by tons of money. ASICs will become more flexible, the cost to design and produce new designs will drop and chip vendors will be eager to find new markets. IT departments simply can't be relied upon to keep up. The attraction of HSM-type solutions is that they end the arms race without the need to constantly upgrade security settings.
>
>> 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.
This is the big problem. We don’t have nearly enough people with crypto-fu to work out these tradeoffs at every bank, retailer, electric utility, government benefit office, etc., etc. We need very clear guidelines, level 1, level 2, level 3 security, that's it.
>
>> 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.
See previous answer. I looked at the yescrypt page. There are a zillion options. Great if you know what you are doing. Not so great if you are an ordinary developer. If I see a website that just says “We proudly use yescrypt” what does that tell me useful about security, nothing I’m afraid without details on the parameter settings.
>
>> 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.)
One major problem is the lack of disclosure by systems as to what security measures they take. So users have to assume the worst—simple fast hashes. We can’t even assume sites use salt.
I do like system generated passwords. I think it is a tool that should be used more widely, especially in highly sensitive situations, e.g. for admins. However, what yescrypt parameters are good enough for 47-bit passwords today? In 5 years? I think that could be and should be spelled out. Slightly off topic: I have a table that generates a mnemonic English sentence for any random password of ten letters (47 bit entropy) diceware.blogspot.com /2013/12/making-random-letter-passwords-memorable.html. I’ve always thought that password generators should offer users a couple of different formats with equivalent strength. Feel free to use my table. Also note that depending on what size words you allow, 3 words with 2 separator characters may be too big for some services (e.g. Microsoft and Medicare).
>
> 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.
Indeed I am.
>
>> 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.
I remember when 6 characters was considered strong. It wasn’t that long ago. We have built cyberspace security around the assumption that ordinary people will do things that are not only inconvenient, but downright impossible given the number of passwords people are expected to remember.
>
>> 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.
There are potential problems with HSMs and the like but they are different in character from the current arms race. Think of the famous knife fight scene in Raiders of the Lost Ark.
>
>> 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.)
>
Again these are positive ideas, but I believe we need to get greater attention to insecure storage for password data and ways to fix. Computer security is collapsing everywhere and the danger of a catastrophic attack on critical infrastructure is widely noted, but little is being done. This is a problem that has solutions. How do we get organized to make something happen?
Arnold Reinhold
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.
