[LEDE-DEV] [PATCH] utils/busybox: prevent weak root passwords

[Dan Lüdtke]

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 <david at 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 at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev