> A lot of the discourse around password hashing gives the impression that there is some magic number you can pick that actually makes passwords safe to use for this kind of thing. There isn’t. They are not. Either your password has sufficient entropy to resist brute-forcing, in which case it is already probably a cryptographic key, or it doesn’t – in which case it will eventually be cracked no matter how many iterations you apply to it.
...but I'm not seeing anything to back that up. Using the article's own example of a 72-bit password entropy that would imply that an attacker is willing to spend up to 4722366482869645213696 times as much brute forcing the password as you are to unlock it normally.
That seems like a fairly remarkable claim to make with little to back it up.
For a sense of scale, even if you're password stretching to just 0.01s, that's 1,496,458,366,089.87 years. You can parallelize that, but let's say you used just 64MB in argon2, and memory costs just 1$/GB - if you're willing to spend 30 billion on ram and get energy and everything else for free, then you can reduce that time to just 50 years; a human working life. And of course, those settings are very light; a spending 10 times time+memory more would barely affect the user, yet cost the attacker 100 times more to hit that 50 year deadline.
Put another way, if the attacker spent the entire US annual GDP buying brute force crackers at 1GB/$ and then a year cracking, that could merely reliably brute-force a 1GB Argon2 stretched password up to 156ms.
I'm sure better hardware would help a bit here, and using PBKDF2 rather than Argon2 surely is weaker (I'd be curious how much, though) but this really isn't a a trivial problem, and the claim from the article looks at the very least unsupported.