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

argon2 password hash consumes too much memory #14294

Closed 6543 closed 3 years ago

6543 commented 3 years ago

In current config it takes 64M for one hashing.

Wee need a less resource hungry default algo.

cc @kaepora @zeripath

refs:

zeripath commented 3 years ago

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 commented 3 years ago

I agree with @zeripath on this

lunny commented 3 years ago

And we should also update the document with some warning .

lunny commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

Further discussion can be moved over to https://github.com/go-gitea/gitea/issues/14702 instead of a closed issue. 🙂