How can we make argon2 safe? #6878

New Issue

GiteaMirror · 2025-11-02T07:09:45-06:00

GiteaMirror commented

2025-11-02 07:09:45 -06:00

Originally created by @zeripath on GitHub (Feb 16, 2021).

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

Originally created by @zeripath on GitHub (Feb 16, 2021). 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

GiteaMirror added the type/proposal label 2025-11-02 07:09:45 -06:00

GiteaMirror closed this issue

2025-11-02 07:09:46 -06:00

GiteaMirror commented

2025-11-02 07:09:46 -06:00

@zeripath commented on GitHub (Feb 16, 2021):

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.

@zeripath commented on GitHub (Feb 16, 2021): 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.

GiteaMirror commented

2025-11-02 07:09:46 -06:00

@lunny commented on GitHub (Feb 17, 2021):

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

@lunny commented on GitHub (Feb 17, 2021): Argon2 memory usage could be configured by Gitea so that users could chose suitable variable according his system.

GiteaMirror commented

2025-11-02 07:09:47 -06:00

@zeripath commented on GitHub (Feb 17, 2021):

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

@zeripath commented on GitHub (Feb 17, 2021): That is point 2: Expose and make configurable the parameters used for hashing.

GiteaMirror commented

2025-11-02 07:09:47 -06:00

@vladionescu commented on GitHub (Mar 4, 2021):

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?

@vladionescu commented on GitHub (Mar 4, 2021): 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?

GiteaMirror commented

2025-11-02 07:09:47 -06:00

@jolheiser commented on GitHub (Mar 4, 2021):

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

@jolheiser commented on GitHub (Mar 4, 2021): It's pertinent to point out that you [_can_ still use argon2](https://docs.gitea.io/en-us/config-cheat-sheet/#security-security), it just isn't the default anymore.

GiteaMirror commented

2025-11-02 07:09:47 -06:00

@zeripath commented on GitHub (Mar 4, 2021):

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 on GitHub (Mar 4, 2021): 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.

GiteaMirror commented

2025-11-02 07:09:47 -06:00

@zeripath commented on GitHub (Mar 8, 2021):

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 on GitHub (Mar 8, 2021): 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.

GiteaMirror commented

2025-11-02 07:09:47 -06:00

@zeripath commented on GitHub (Mar 8, 2021):

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.

@zeripath commented on GitHub (Mar 8, 2021): 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.

GiteaMirror commented

2025-11-02 07:09:48 -06:00

@uwejan commented on GitHub (Jun 20, 2023):

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?

@uwejan commented on GitHub (Jun 20, 2023): 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?

GiteaMirror commented

2025-11-02 07:09:48 -06:00

@wxiaoguang commented on GitHub (Jun 23, 2025):

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

There are different algorithms and they are configurable.

@wxiaoguang commented on GitHub (Jun 23, 2025): ``` algoBcrypt = "bcrypt" algoScrypt = "scrypt" algoArgon2 = "argon2" algoPbkdf2 = "pbkdf2" ``` There are different algorithms and they are configurable.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#6878