Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Make captcha and password optional for external accounts #6606
This is part of the group of work for collective UX improvement and account security related to passwords and secondary accounts.
@@ Coverage Diff @@ ## master #6606 +/- ## ========================================== - Coverage 41.24% 41.22% -0.03% ========================================== Files 467 467 Lines 63336 63360 +24 ========================================== - Hits 26124 26121 -3 - Misses 33796 33823 +27 Partials 3416 3416
referenced this pull request
Jul 1, 2019
This is not particularly true.
It is very likely that a programmer will make a mistake (whether already in the past, or in the future), in which a comparison is made between some API or Form input and the password, not checking to see if the password is blank.
It is very, very unlikely that the programmer will accidentally check the password against a pre-computed random string.
My commits have been aimed at providing authentication patterns that are both more secure and easier to use than the default password authentication. My hope is that one day passwords will be disabled by default and you will have to specifically opt-in to using a password with some sort of "warning: you're opening up your gitea instance and all of your users to pwnage". Hence
That said, call it what you will.
Hi @solderjs I understand what you're saying about comparing empty passwords to empty strings - but we've already had to deal with this problem and have already fixed it. So whilst your concern would be correct - we've got the fix in.
Now because of our logic - if the password is empty we can assume that the password is not set. Thus we can migrate to remove the local password in future easily - because an empty password is an unset one. Yes, I agree this is not ideal and I would prefer to do this properly - however we cannot do that at this point in 1.9. If you stick a random password in - I won't be able to do that migration in future.
Removing the special status of the local db password is on my personal list of things to do, but my list is long. The technical debt of Gogs is very large IMHO.
I do appreciate what you're aiming for though.