Argon2 Wins Password Hashing Competition | Hacker News Reader

Argon2 Wins Password Hashing Competition

password-hashing.net

122 pointstptacek27 comments

It is still just fine to keep using bcrypt, scrypt, and PBKDF2 --- but it wouldn't make much sense for them to have a Password Hashing Competition and not conclude it by recommending some algorithm over all the others.

The real distinction isn't between apps that use the PHC winner and apps that use "legacy" password hashes, but instead between apps that use serious password hashes at all and apps that just use SHA hashes.

Still: an interesting development!

In fact, for the time being, I'd still recommend new development use bcrypt or scrypt (and not PBKDF2 for the simple fact that typical APIs around it aren't specifically tailored to password hashing, don't handle salts transparently, etc.). Argon2 winning is great, and it's almost certainly an improvement over existing methods, but it's also still relatively new and should be approached with typical caution.

> PBKDF2

Of which I'm a huge fan because you can easily build it out of stuff that any crypto library has. This is incredibly useful in certain situations where you need to check against passwords from different languages and environments.

Implementing bcrypt or scrypt from scratch if you have nothing to interface with is … tricky.

scrypt isn't actually too difficult to implement from scratch, although somewhat ironically it requires PBKDF2.

That's not so much irony as coincidence.

Bcrypt and scrypt don't suck.

Only use PBKDF2 if you are comfortable with a function that a GPU-using attacker can evaluate many hundreds of times more efficiently (in terms of energy cost) using hardware that hundreds of times cheaper (in terms of $/guess/s).

Expressed in terms of log base 2, by using PBKDF2 you're leaving several bits of security on the table. And most folks agree that passwords need all the effective entropy they can keep.

Or md5...

For what it's worth, I'd say that the true winner of the PHC is scrypt: Half the candidates were just minor tweaks to scrypt, and nobody achieved any substantive security increase over what scrypt provides.

Instead of just recommending one across the board, I wish they'd be specific about the requirements required for it to be considered the best choice. For example, is it the best choice for computing a hash on a RPi A+ that has a max of 256MB memory?

Also, the benchmark it includes only benchmarks Argon2. Would be nice to have a benchmark that compares it to a variety of commonly-used hashing algorithms that could be run on lower-end systems along with a way to report them, then those reports could be collected and published.

I also worry when I read something that sounds like whitepaper-speak in something trying to pass itself off as a scientific paper:

"Our solution We offer a hashing scheme called Argon2. Argon2 summarizes the state of the art in the design of memory-hard functions. It is a streamlined and simple design. It aims at the highest memory filling rate and effective use of multiple computing units, while still providing defense against tradeoff attacks. Argon2 is optimized for the x86 architecture and exploits the cache and memory organization of the recent Intel and AMD processors."

Most of the motivation of a password hash function derives from the attacker's resources, not the defender's. Realistic designs will nod to the defender's constraints (Argon2 is designed to work especially well from x86), but the bulk of the design work is in thwarting attacks launched from optimal hardware dedicated entirely to the proposition of breaking that hash.

So it's not entirely a great idea to try to find a password hash optimized for e.g. low-power ARM applications. You should just use Argon2 (in a new design, if the reference code works for you), or bcrypt/scrypt/PBKDF2 if you don't have good code for Argon2.

Following that, wouldn't the best idea be to increase the requirements such that you need something ridiculously intense to compute it, like a Tianhe-2? Something that requires more intense hardware may be the best algorithm, but at some point you need something practical.

If all other methods are insecure, then you wouldn't want to encourage those and would want to warn others. But, is it really that much more secure than the others?

You can do this in practice by simply increasing the cost parameters. Actually requiring this would be a fantastic way of authoring a spec that nobody uses in practice. The point of a password hashing function is not to simply produce the hardest possible hashes to crack — it's to do so given the resources the defender has available to allocate.

> it's to do so given the resources the defender has available to allocate.

That's my point exactly.

For any popular currently-sold piece given hardware, it would be nice to know which algorithm should be used rather than to just say, "This is better. Use this which requires better hardware."

Don't get me wrong. I appreciate all of the work, but there are people that run on hardware that isn't as capable, so I think making blanket statements about what's best may not be the right idea. Qualify it at least.

I think you're missing a subtlety of the design here. When we talk about the hardware it takes to "run" these constructions, we are (mostly) talking about the requirements we impose on attackers.

Argon2 will work fine on your RPi A+.

Cool.

So, when it states, "Argon2 is optimized for the x86 architecture and exploits the cache and memory organization of the recent Intel and AMD processors," and "We recommend Argon2 for the applications that aim for high performance. Both versions of Argon2 allow to fill 1 GB of RAM in a fraction of second, and smaller amounts even faster," that does not indicate that Argon2 might not be the best choice for something like a RPi A+? Because that confused me. It really seemed like something that assumes better hardware to be a good choice.

I believe so. If you're memory-limited, then no matter what hash you use, you might be limited in how high you can turn the memory-hardness pain crank. But you still want that dial turned as far forward as you can.

But the situation you're describing is why all password hashes, including the three "legacy" hashes (bcrypt scrypt PBKDF2) are parameterized by cost factors.

But on hardware for which the hash function implementation is optimized, you will be able to crank up the cost factors higher than on comparable hardware for which no optimization was done. So a different hash with an implementation optimized more for ARM could give more protection than Argon2 on ARM because you would be able to use higher cost factors while still using the same amount of wall clock time. But I don't think such a hash function exists, and if not you could as well create a more ARM optimized implementation of Argon2.

Well, yes - better hardware is a better choice. You're in a race with an attacker trying to reverse your password hashes.

You should feel safe in assuming that this algorithm will turn your CPU cycles spent into the highest attacker burden that any algorithm will. In this case, they're saying that they've used the new hardware features efficiently so they're able to increase the cost multiplier even more by doing harder work in the same time.

Just use whatever number will make it complete in a second, it's what you're gonna get.

But wouldn't the problem be that you would be exposed to a DDOS attack? All the attackers would need to do is to try to login many times to your servers and they would be buried calculating hashes.

One of the ways for embedded devices to address this is require a hardware resident key is part of the hashing process (handled in hardware). Otherwise, if someone can get the hashes, you're not going to be able to find cost factors that provide good user experience and are also resistant to off device attacks.

I think I'm having trouble coming up with the embedded hardware use case that requires real-time validation of lots and lots of different passwords. Because if all you have is a couple of passwords, you have a lot more wiggle room for your hash performance than most Rails apps do.

Wouldn't a (high entropy) shared secret be more appropriate authentication scheme for connecting to a low power device like that?

This is entirely dependent on whatever thing you're trying to build.

Related previous discussion: https://news.ycombinator.com/item?id=9917712

Yep. Today triggered by this tweet:

https://twitter.com/veorq/status/661242728513187840?lang=en

Any info on how they rate/compare the algorithms? I could not find anything on the site. In particular, it would be nice to see how bcrypt/scrypt/PBKDF2 rate.

Since bcrypt and PBKDF2 aren't even memory-hard, and PBKDF2 is especially easy to speed up with hardware, the answer is "comparatively, not well".

They're all still light years better than DIY salted hashes.

Reply on news.ycombinator.com