
Argon2 Wins Password Hashing Competition - tptacek
https://password-hashing.net/
======
tptacek
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!

~~~
the_mitsuhiko
> 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.

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

~~~
stephenr
That's not so much irony as coincidence.

------
lighthawk
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."

~~~
tptacek
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.

~~~
lighthawk
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?

~~~
stouset
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.

~~~
lighthawk
> 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.

~~~
tptacek
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+.

~~~
lighthawk
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.

~~~
tptacek
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.

~~~
JanKanis
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.

------
ademarre
Related previous discussion:
[https://news.ycombinator.com/item?id=9917712](https://news.ycombinator.com/item?id=9917712)

~~~
tptacek
Yep. Today triggered by this tweet:

[https://twitter.com/veorq/status/661242728513187840?lang=en](https://twitter.com/veorq/status/661242728513187840?lang=en)

~~~
carterehsmith
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.

~~~
tptacek
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.

