search

technion / ruby-argon2

A Ruby gem offering bindings for Argon2 password hashing
MIT License
229 stars 30 forks source link

Possible to remove hard-coded upper limit on t_cost? #21

Closed dgpokl closed 6 years ago

dgpokl commented 6 years ago

I've been implementing argon2 and in testing using the argon2 CLI I determined that a t_cost of 500 and an m_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 keeping t at 10 would be costly in terms of server capacity. I can technically turn m 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 with t. 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.

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

technion commented 6 years ago

I've pushed a fix. You'll probably appreciate a release, I'll do one tonight.

dgpokl commented 6 years ago

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.

technion commented 6 years ago

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