argon2 password hash consumes too much memory

[6543]

In current config it takes 64M for one hashing.

Wee need a less resource hungry default algo.

cc @KAepora @zeripath

refs:

• Secure Defaults for HTTPS/TLS and for Password-Based Key Derivation #10602
• Use argon as default password hash algorithm #12688

[zeripath]

Thinking on I think leaving argon2 as the default is OK - however we should ensure that Users can set it on the install page. (and there is appropriate warning next to the option so our low resource/heavy load Users can choose something different.)

Leaving ourselves in a secure state by default is helpful.

[lafriks]

I agree with @zeripath on this

[lunny]

And we should also update the document with some warning .

[lunny]

A PR is needed to add an option on installation page with warning or we should change the default password hash algorithm. Since most Gitea users have small memory instance, this is very important for them.

[zeripath]

Having spent even more time dealing with more issues that have essentially come down to argon2 I have changed my mind on the above comment.

I now think we should just change it.

Our users cannot really be expected to think that their memory problems and slow downs are due to a password hashing algorithm.

[zeripath]

I guess the question is what should be the default? I guess we just move back to pbkdf2 but make it settable on the install page with warnings about the issues.

[vladionescu]

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?