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