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.