Closed dgpokl closed 6 years ago
Most people would consider a one second hash time a DoS attack. This library was built with overly "safe" values to prevent someone doing something silly.
This had, at a root cause, a highly aggressive email I receive from someone who DoS'ed themselves with a similar library I wrote.
If much higher values of t_cost suit your needs and use case, I'll raise the limitation. This will be released shortly.
I've pushed a fix. You'll probably appreciate a release, I'll do one tonight.
Thanks for the words of caution and also for the responsiveness. I may reconsider. Overall, just trying to follow best practices here and don't want the 'cure' to be worse than the disease.
@dgpokl In terms of best practice, the official paper has a "recommended parameters" section here:
https://github.com/P-H-C/phc-winner-argon2/blob/master/argon2-specs.pdf
Unfortunately it doesn't suggest a reasonable timeframe, but asks you to identify one. So you may feel one second is fine.
Most top Google hits for bcrypt recommendations suggest 0.1s to 0.3s.
I've been implementing argon2 and in testing using the argon2 CLI I determined that a
t_cost
of 500 and anm_cost
of 12 was ideal and gave 1-second hash times. When I try to use the ruby-argon2 gem, I found that it restricts t to a maximum of 10. This seems strange to me given that the hard-coded limit for m_cost is 2^31 or 2GB. This seems like an unwise amount of memory to use for password hashing in practice, but is allowed, yet iterations is capped at a very low number which, unless you're using a huge amount of RAM, gives very quick hash times on current hardware.Trying to increase
m_cost
to get my desired result while keepingt
at 10 would be costly in terms of server capacity. I can technically turnm
up on my existing hardware as far as 15 (16 gets the process killed), but again, I'd rather not consume that much memory when I can achieve the desired hash time witht
. Also, t=10 and m=15 on my hardware is only 409ms.Is there a reason for this limit, or is it arbitrary? Is it possible to at least move these hard-coded integers to constants so that this limitation can be more safely patched around? Happy to make a PR for this if you're open to it.