How can we make argon2 safe?

[zeripath]

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]

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

• Act like GitHub and ban basic auth with passwords - require tokens instead.
• Expose and make configurable the parameters used for hashing.
• Add a max concurrent lock around password hashing.

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]

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

[zeripath]

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

[vladionescu]

Moving my comment over from #14294 (comment) (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]

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

[zeripath]

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]

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]

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]

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?

[wxiaoguang]

	algoBcrypt = "bcrypt"
	algoScrypt = "scrypt"
	algoArgon2 = "argon2"
	algoPbkdf2 = "pbkdf2"

There are different algorithms and they are configurable.