search

go-gitea / gitea

Git with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD
https://gitea.com
MIT License
45.12k stars 5.49k forks source link

How can we make argon2 safe? #14702

Open zeripath opened 3 years ago

zeripath commented 3 years ago

Argon2 is clearly causing multiple problems due to its memory requirements, especially on lower spec'd systems.

I cannot recommend argon2 in good conscience at present as its memory use can be unbounded especially under LFS.

Ref #14674

zeripath commented 3 years ago

Ok there are multiple options here, any and potentially all of which should be implemented:

I understand a user on discord is looking in to the second option right now - but I think we seriously need to consider both of the other options in addition.

lunny commented 3 years ago

Argon2 memory usage could be configured by Gitea so that users could chose suitable variable according his system.

zeripath commented 3 years ago

That is point 2: Expose and make configurable the parameters used for hashing.

vladionescu commented 3 years ago

Moving my comment over from https://github.com/go-gitea/gitea/issues/14294#issuecomment-790765537 (sorry! found that via the PR linked in latest release notes)

Mostly interested in what the symptoms are here that we're trying to solve by ditching Argon2.

What issues have we seen from this memory usage? I personally haven't encountered slowdowns, but my instance only has ~20 users so I am certainly not running a very busy Gitea.

Like a good KDF, Argon2 is designed to not be performant. If it was performant, it would be easy for attackers to brute force plaintext passwords should they ever get their hands on the hashes.

That said, it's also not meant to be a drag on the whole system. It has configurable parameters that influence memory usage, among other things. Have we considered tweaking those knobs or exposing them to admins, so they can be turned down for more resource constrained deployments?

jolheiser commented 3 years ago

It's pertinent to point out that you can still use argon2, it just isn't the default anymore.

zeripath commented 3 years ago

OK I absolutely do not want this issue to turn into other issues that go round in circles without solutions.

So further comments that do not address the memory issues with argon2 and the solutions proposed above or propose other solutions WILL be deleted.

Mostly interested in what the symptoms are here that we're trying to solve by ditching Argon2.

It is not prudent to explain further than I have stated above: its memory use can be unbounded especially under LFS.

@vladionescu If you want further explanation come to discord and chat to me directly.

zeripath commented 3 years ago

Blake3 is not a password hashing algorithm. Do not use Blake3 for password hashing - it has none of the characteristics you need in password hashing.

zeripath commented 3 years ago

Fundamentally the issue is that hashing passwords is supposed to be expensive and has to be expensive in order to provide protection against cracking. Changing algorithm and adjusting its parameters etc. is not going to form a complete solution to this problem - it may well form part of the solution in order to tune parameters for running systems and allow more concurrent password checks - but it is not the solution.

If we allow unlimited password validation we are going to run out resources simply because password validation is expensive.

Our only options are to limit the amount of concurrent password validation actions on the server and to move users of the API and HTTP from using passwords to using tokens which are far less expensive to validate.

uwejan commented 1 year ago

Hey guys, I am oticing an increase of memory consumtion of 4 MB on a single user request to verify a password? That is too much is not it. is thre a way around this?