[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.

[fineman]

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.

[cm2187]

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.