What the... This discussion has become a bit out of hand! My goal was to have consistency at LuCI and CLI. I see how enforcing passwords of a particular kind, as well as enforcing passwords at all, is not an engineering decision. I have no problem with this patch being rejected.
So, since we decided to not enforce anything regarding passwords for the root user on CLI, I think we should also not enforce anything regarding passwords for the root user on LuCI. Still, I am concerned about consistency foremost. This PR needs to be rejected to stay consistent, then! --> https://github.com/openwrt/luci/pull/878 Cheers, Dan PS: Ah, I see that patchwork rejected the patch already. All good! > On 17 Feb 2017, at 13:51, David Lang <da...@lang.hm> wrote: > > On Fri, 17 Feb 2017, Alberto Bursi wrote: > >> On 02/17/2017 12:52 PM, David Lang wrote: >>> On Fri, 17 Feb 2017, Alberto Bursi wrote: >>> >>> And having no password is a much bigger change than having a short >>> password when you are testing things. It makes a lot of sense to be >>> excercising the password routine when doing tests, and very little >>> difference if you are excercising it with a short password or a long one. >>> >> >> What? if I'm testing things that are completely unrelated to login >> (system configurations for tutorials or stuff for device support) then >> how I log in is irrelevant. > > if you are testing specific features, than any other features are irrelevant, > but if you are doing more general testing, then one of the things that needs > to be in the tests is the authentication. > > and if you are setting up test scripts, it's best to make them scripts that > users can test with as well, and they are almost always going to have > authentication enabled. > >>> Why are you saying that short passwords are bad? Is it just because you >>> have been told that they are? >>> >>> Remember, a short password is only a problem if attackers have the >>> ability to make brute force attacks on the system. If attackers can't >>> get at the interface, or if there are other strategies in place to >>> defeat brute force attacks, a short password can be acceptable. >>> >> >> True. Are there such systems in place for ssh access? > > They are available. > > To start with, SSH access is not enabled on the WAN side. > > If password brute forcing from the inside is considered a threat, then > turning on rate limiting/temporary lockouts/alerts/etc is a far better thing > to do than to try to force 'better' passwords. > > people who don't want good passwords are going to find a way to not have good > passwords. > > password1! is not a much better password to use than password, even though > the password strength tests will claim that it is. If you force people to > have 'longer' or 'more complex' passwords, they are far more likely to add > some easy to guess nonsense on the end of their previous 'bad' password than > to come up with a 'good' password. > > David Lang > > _______________________________________________ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
