-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use argon as default password hash algorithm #12688
Use argon as default password hash algorithm #12688
Conversation
Signed-off-by: Andrew Thornton <art27@cantab.net>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Is it worth it to create a migration to update the default value?
Remember it's a hash. You don't have the original password so you can't write a migration you just have to let people login, test against the old hash and update to the new hash. The only other option is forcibly resetting everyone's password which we could make a doctor command for I guess? |
By migration I meant just the default value for the column rather than the content of the column itself, as otherwise the sync2 will update it. Although if we wanted to also update the column content we could have something in login that catches if existing hash is using different algo and update when the user is logging in. |
Codecov Report
@@ Coverage Diff @@
## master #12688 +/- ##
=======================================
Coverage 43.29% 43.29%
=======================================
Files 646 645 -1
Lines 71592 71560 -32
=======================================
- Hits 30993 30985 -8
+ Misses 35583 35554 -29
- Partials 5016 5021 +5
Continue to review full report at Codecov.
|
What about specific notes for migrating for pbkdf2 to argon? Simply changing |
yes simply changing the app.ini is enough. |
Signed-off-by: Andrew Thornton <art27@cantab.net>
Signed-off-by: Andrew Thornton <art27@cantab.net>
…aults Signed-off-by: Andrew Thornton <art27@cantab.net>
Should this have included a migration? I'm seeing these warnings (MariaDB):
|
Yeah, this should have migration to change default for column |
Can't change default columns without recreate-table. |
fortunately we now have recreate-table |
so if it's really wanted we could use recreate-table in a migration |
go-gitea#12688 changed the default for the user table leading to sync2 warnings Unfortunately changing defaults requires a complete table rewrite in general. However, just dropping columns could be bad - so this PR leverages the techniques used in recreate table to recreate from the inferred schema and recreates the user table. This is not necessarily the correct thing to do - but code sometimes speaks louder than words. Signed-off-by: Andrew Thornton <art27@cantab.net>
* Add migration for password algorithm change #12688 changed the default for the user table leading to sync2 warnings Unfortunately changing defaults requires a complete table rewrite in general. However, just dropping columns could be bad - so this PR leverages the techniques used in recreate table to recreate from the inferred schema and recreates the user table. This is not necessarily the correct thing to do - but code sometimes speaks louder than words. Signed-off-by: Andrew Thornton <art27@cantab.net> * oops Signed-off-by: Andrew Thornton <art27@cantab.net> * ok lets use the shorter bits for other dbs Signed-off-by: Andrew Thornton <art27@cantab.net> * Update models/migrations/v150.go * Update models/migrations/v150.go * fix migration Signed-off-by: Andrew Thornton <art27@cantab.net> * mv v150 to v151.go Signed-off-by: Andrew Thornton <art27@cantab.net> Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com> Co-authored-by: Lauris BH <lauris@nix.lv> Co-authored-by: techknowlogick <techknowlogick@gitea.io>
This is a partial repush of #10602
Changes to Password-Based Key Derivation
Currently, Gitea uses pbkdf2 as the default password hashing function. In this pull request, I replace that with argon2 as the default, for the following reasons:
pbkdf2 is uniquely vulnerable to GPU and ASIC-based attacks that argon2 and scrypt are much less vulnerable against.
pbkdf2 is vulnerable to acceleration attacks and to a host of other attacks that argon2 and scrypt are not vulnerable to.
Therefore, given the above and especially given that argon2 is a well-specified, formally studied design that has won the Password Hashing Competition, I think using it as the default instead of pbkdf2 makes complete sense.
Closes #10602
Many thanks to @KAepora for initial PR.